From Chaos to Success: Unraveling the Trials and Triumphs of a Million-Dollar Startup Journey
In this essay, we’re going to dive into the behind-the-scenes story of a million-dollar company. This company has experienced rapid growth and has successfully raised $14.5 million in funding through seven rounds.
But, it’s important to note that the company’s journey wasn’t always smooth sailing. As we rewind back to the end of 2017, after approximately 3.5 years and investing over $100,000 across various teams, the founders found themselves without a basic working application.
So, grab a seat and get ready for a wild ride as we unveil the ups and downs of this company’s behind-the-scenes journey.
Reference: check out roomsie.com
The rollercoaster ride of Roomsie
After expending significant amounts of money and time, by the end of 2017, the founders found themselves actively searching for another team to take responsibility for their project and turn it into a functional solution.
Their ambitious goal was to create an app similar to Airbnb, but specifically designed for renting rooms to students and interns in the local area.
During this crucial period, they crossed paths with Vedran and Ivor, two individuals on the lookout for new projects to tackle. Jacob, one of the founders, approached Vedran and initiated a conversation about their venture.
To Vedran’s surprise, he learned that the founders had already engaged the services of a team of developers through a prestigious remote recruitment company, promising access to the top 3% of talent. Yet, despite investing over $100,000, the founders were still unable to develop a basic working application for their startup.
Vedran and Ivor spent ten days inspecting the codebase and closely observed the development process. They had conversations with all team members collectively and individually, aiming to grasp their perspectives and pinpoint the root causes of the problems.
Findings after inspecting the code base
The project was severely mismanaged. The processes in place were overly complex and lacked guidance from an experienced lead developer or someone with project management expertise. Surprisingly, the project was being managed by developers who didn’t hold senior positions, which only added to the chaos.
It was clear that some developers were completely clueless about what was happening. Despite having a team of five developers, two of them were wasting their time on a simple login page. It seemed like they were deliberately stretching out their tasks to maximize their earnings, and the client was bearing the financial burden.
Another significant issue they uncovered was that some developers involved in the project were simultaneously juggling other projects. As a result, it was difficult for them to justify the time they allocated to each task, leading to delays and inefficiencies.
Perhaps most concerning was the absence of clear feature ownership. No one on the team took responsibility for failing to deliver on their assigned tasks, leading to a lack of accountability and an overall sense of chaos.
Imagine spending over three years on a project and realizing that even the homepage wasn’t fully developed. It’s a frustrating situation, to say the least.
Then, Vedran and Ivor compiled their findings into a comprehensive report and shared it with Jacob.
To ensure an unbiased assessment, Jacob decided to seek a second opinion and hired another firm based in the USA to evaluate the project’s progress and processes. Not surprisingly, the results from this independent evaluation aligned closely with the initial findings from Vedran and Ivor.
After reviewing the findings from both teams, Jacob approached Vedran to ask if they could take over the project. Determined to bring about a positive change, they made the bold choice to downsize the team from five members to three. They added J, an experienced developer specializing in Ruby and backend development.
With J specializing in backend development and Ivor taking charge of the front-end application, Vedran led the team and provided support whenever needed. Together, J, Ivor, and Vedran swiftly developed over 80% of the application within a few months, transforming the project’s trajectory.
The first round of testing the app with a small group of users
Once the app was ready, they invited a small group of people to test it out. They initiated the first round of payments, and some renters began using the app. However, they soon encountered bugs and issues with the payout system. The team had to endure a frustrating wait of around three months for the payouts to be processed, and the overall experience became buggy.
To handle payments, the team had initially implemented Assembly Pay. However, Vedran was skeptical about this choice since Assembly Pay was a relatively new startup and not yet stable. As it turned out, it was not a good fit for the project.
Unfortunately, the third developer, J, had to move on from the team. In response, Vedran took over the backend responsibilities and made the decision to remove Assembly Pay and integrate the more reliable Stripe payment gateway. However, this seemingly simple task proved to be unexpectedly complex due to poor programming practices, which many programmers unknowingly fall into.
Tight Coupling with Third-Party API Integration
One of the team developers who implemented Assembly Pay built a significant portion of the application around that API. This is a classic example of tight coupling between the application code and the third-party API, generally considered poor coding practice. The problem arose when they decided to switch from Assembly Pay to Stripe, as it required rewriting a significant amount of code that was closely tied to the Assembly Pay API. This approach introduced unnecessary complexities and frustration.
Tight Coupling and its Solutions
Tight coupling happens when two components rely heavily on each other, making it hard to modify or replace one without affecting the other. To enhance the code, developers can use loose coupling principles, which reduce dependencies between components for flexibility and easier maintenance.
There are many ways to ensure the code isn’t tightly coupled but a key practice is writing modular code that separates concerns.
Separation of concerns is crucial in software development. It involves dividing the codebase into modules, each handling specific tasks. When integrating a payment gateway, separating its code brings benefits. It reduces interdependencies, minimizing extensive code rewriting when making changes. It also enhances code readability, comprehension, and collaboration among team members.
Due to the lack of following this practice, Vedran had to rewrite a significant amount of code to replace the Assembly gateway with Stripe. However, their effort proved worthwhile. They resolved additional payment issues and successfully launched the product. Within weeks of the launch, bookings started pouring in, and the company began generating substantial revenue in the six-figure range.
Lessons from this journey
The company, with the potential to become a million-dollar enterprise, faced initial setbacks due to poor management and leadership. From this story, we can derive several valuable lessons:
One lesson for developers
Always ensure that you follow established good programming practices in the industry. Learn basic design patterns and collaborate with your team to create a plan before starting coding. This way, you can avoid facing consequences later, like Vedran’s team had to while implementing the payment gateway API. If they had followed good coding practices from the beginning, they wouldn’t have had to rewrite a lot of code. It saves time, energy, and money.
Two lessons for founders/clients
- Competence Over Size
The size of a team or its reputation in the industry doesn’t guarantee the success of a project. It’s the competence and expertise of the team members that truly matter. A smaller team with skilled individuals who possess the necessary technical knowledge and experience can often outperform larger teams. Their ability to work efficiently, collaborate closely, and make quick decisions can result in a more streamlined development process and timely project completion.
- Transparency in Processes
Additionally, transparency is crucial in development processes, particularly when the founders or clients have a limited technical understanding. It’s not uncommon for non-technical founders to be taken advantage of if they are not actively engaged in the process. By proactively seeking information about the team’s processes, clients can ensure that they remain informed and involved throughout the entire development loop. This open communication fosters trust between the client and the development team, as well as enables the client to provide valuable input and feedback, ultimately leading to a successful outcome.