Rapid Growth Experience from 0 to 100M: Setbacks and Right Decisions
Recently we have raised an investment round of $2M that will allow us to strengthen our core team and set up headquarters in London. As a new exciting journey is in front of us, it is time for some reflection on our hard times and what we should remember while continuing our expansion.
Today, I’ll be sharing some practical tips on how to be technically and organizationally prepared for rapid growth by setting up the necessary processes in a startup. Rapid growth is something that I sincerely believe every project will attain sooner or later. This article is based on the experience of my team, having survived a rapid growth between April 2020 and April 2021, where we went from zero users to 100 million per month. During this period of time, we had learned a lot, and we’re continuing to successfully grow even today. As of writing this article, our user base comprises over 150 million users.
The context behind rapid growth
Before we move on to specific steps and recommendations, I’d like to mention the four main startup characteristics that go into forming the context of rapid growth.
1. Short operational life
At launch, a project has no reputation. This, on one hand, comes as an advantage. It grants the freedom to experiment and make mistakes; nothing you do will affect your company’s image. Your servers being constantly down won’t get mentioned in the media or announced on large pages. On the other hand, a lack of reputation means a lack of credibility. Having zero reputation can make it easier to go into the red and lose a client.
2. Finding a replicable and scalable business model
At the beginning of a startup’s development, finding a business model that generates a profit is essential. You might have a weak product and not enough manpower, yet you have to figure out what will make you millions. This will eventually be asked of you by investors and businesses, which means you’ll need to develop a lot of features. A lot of features to validate product ideas.
3. Rapid growth
Rapid growth itself means a change in development context. Yesterday’s tasks become irrelevant and tomorrow’s challenges become fatal for you as they weren’t included in your process. Rapid growth is only one part of your startup’s particular state. You can’t just focus on the fact that you’re going to grow fast.
Uncertainty is also an important factor that needs to be considered alongside rapid growth. Sure, our startup’s client base might be growing by 8% each week right now, but a year and a half ago, we weren’t concentrating on growth rate predictions. We had a small team (albeit about the same size as we do now), a small client base, and the ever-pressing question of “will we see growth at all?” Our key focus at that time was to develop features that would set the stage for that growth.
Given such factors as high uncertainty, the need to release new features to millions of users, and a team of only a few people, how can a project grow and scale so quickly?
The answer is simple: it can’t. You will always have dissatisfied parties and expenses. All you can do is keep those costs down and try to reduce them to zero.
What follows are recommendations based on our own experience, and it’s worth saying a few words about Qonversion and our own context.
Qonversion is a mobile infrastructure and API for mobile apps with subscriptions. Our SDKs provide APIs to work with Apple and Google payment systems, specifically the Google billing client and the Apple App Store. In addition, it comes with analytics, testing, AV tests, trigger automation for sending push notifications to customers, returning users, and so on. This entire infrastructure is maintained by a team of seven technicians.
Here’s our context: we have a technically complex product (essentially a software as a service with a whole set of functionalities), a hard-to-predict infrastructure load, and a small team.
Startup thought paradigms
The development of most startups is based on two approaches, essentially two thought paradigms. One is wanting to anticipate most problems that could arise in a project, and the other is wanting to get results quickly.
How architects do it, or “long-term, but high-quality”
When I say wanting to anticipate most problems, I’m talking about that great feeling at the project’s launch. It doesn’t matter what kind of project it is: a presentation, pet-project, or a new service in your company without existing guidelines. This feeling and desire to do things differently, to take all past experiences into account, to design an adaptable architecture, and choose the right tools and approaches. The thought, “I’m going to take my time and do things right” is probably familiar to some of you. Long-term, but high-quality.
This is how architects do it. An architect is a perfectionist – a person with a systemic mindset. They like to do everything with exceptional quality and adaptability, through fleshed-out systems, and with the fruits of previous projects taken into account. This person is very systematic, with all their affairs neatly organized and correctly structured.
How hackers do it, “fast, but not flexible”
There’s another approach, too, a more product-oriented approach involving developing a project and solving only business-related issues.
This is how hackers do it. A hacker is an X-shape engineer who knows their way around quite a fair number of tools. They can quickly, and quite literally in a weekend, build up an entire system. The fault tolerance, flexibility, and maintenance potential of that system will remain under question, however.
This is, of course, all abstractly-speaking. These paradigms of thought don’t usually present themselves so extremely, I assume. It’s still important for us to keep these extreme thoughts in mind in order to understand how we act at any given time.
There is no right or wrong paradigm
History is dotted with examples of both the first paradigm, when startups were met with phenomenal results after taking their time building up their projects, and examples of the second paradigm, when Airbnb developers launched their app in literally one weekend, validating an idea.
Given that you work in a startup, you can’t run with two paradigms at the same time. In a large company, you can have a Growth Team, which quickly validates certain features, or, on the contrary, you can have a strictly-aligned, stable development process. In a startup, you take one or the other approach. Again, it’s very important to emphasize that there’s no right or wrong here; you need to follow the path that you prefer most at the first stage of development.
Qonversion, in particular, began with an API for mobile apps; it was a pet-project of a pet-project. There were absolutely no requirements for it, and it was developed rather quickly, literally in a weekend, but we then had to spend a long time rebuilding that paradigm. The hardest thing for us to grasp was that the thought paradigm we had launched with was still propelling the project forward by inertia by the time we needed to rebuild it.
How to structure processes in a startup and sustain rapid growth
1. Decide on a thought paradigm that suits you
Deciding on a thought paradigm means determining the optimal ratio of task processing time to the time needed to accomplish the task itself.
The minimum theoretical figure that I’ve established is about 20% for processing. Anything less than 20% would suggest that you’re iterating too quickly, focused solely on the result, with no regard for quality. There are more accurate metrics, such as the percentage of task returns, the number of bugs found after release, and so on. In a startup, these metrics are not as relevant due to the fact that you are operating in a volatile ecosystem.
2. Determine your priorities
It’s important to set team priorities for the next three to six months. Predicting what will happen after six months is difficult, so every three months you need to get the technical team, the product team, and the business team together to discuss the direction the project is headed. One key problem that often arises in a startup is misaligned visions, when the technical team does something high-quality, for many years, and the business team needs to quickly validate the idea. For the most part, we’ve been able to avoid these problems, but there have been features that we’ve developed for quite a while instead of quickly releasing them to the market to validate the concept.
3. Build a risk map
There are quite a few approaches in building a risk map, but to put it briefly, it is the ratio of the likelihood of a task’s implementation and the impact of that task on metrics: service downtime, customer loss, customer refusal to use the service, and others.
4. Predict growth outlook
Once you’ve built a risk map, prioritized tasks, and figured out your approach to problem solving, you need to project a growth outlook for your project by a factor of two, five, and ten.
A 10x figure may look ambitious, however in practice, in a startup, that growth can arrive in a few months. B2B services can get huge clients with a huge user base, and an agency might get in touch with you. That is why predicting x10 growth prospects and trying to anticipate which systems will fail with that kind of growth is a must.
It was precisely this kind of forecasting last April that gave us the opportunity to expand our infrastructure over the course of the year. The refactoring we did at the time was partially unjustified based on business metrics, but still allowed us to scale quickly at the right time.
5. Keep your fingers on the pulse
Once you’ve defined your thought paradigm, you can continue to operate within the same approach, but remember to pay attention to signals from different parts of your business and technical team that something might be going wrong. The support system could get overloaded, which might mean that your business has grown and that the technical side of things is messy. When you identify your risk map and prioritize, it’s easy to figure out what’s going on with the codebase at a given moment.
6. Fix your losses
During the refactoring process, you may sometimes switch over prematurely to systems’ scaling because you don’t have an understanding of whether or not there will be growth. You might do it incorrectly, or, on the contrary, you might start making an MVP feature, and demand for it might turn out to be very high and you need to do it well. An important tip here is to be able to fix losses, to do so bravely and swiftly.
One of our key mistakes was trying to get fairly large features into production when we couldn’t fix a loss for two or three weeks of development. Instead, we kept increasing the time frame. This is why you have to be in sync and keep your fingers on the pulse all the time.
7. Learn to readjust your thought paradigm
If you’re testing a hypothesis and decided to develop a feature over the sprint, put it into production, and look at analytical indicators, you need to learn to adjust your thought paradigm. Hackathons, quarterly, two or three-week code refactorings are well suited for this, when your entire team stops all product development and focuses solely on quality and tests.
By periodically switching from a thought paradigm of generating MVP features to a more long-term perspective of building system resilience, you learn how to do so quickly.
We had a positive experience building a feature over a two days that got validated. Next thing you know, we rebuilt it. And vice versa, when we stopped all product development for a month and refactored the system.
The importance of people
When talking about the technical approaches your development is built around, you need to bring up the most important thing – people. People provide the rapid growth that your project will have.
1. Have trust
90% of startups close or face many problems because a small team doesn’t establish the culture or relationships that should facilitate rapid growth. Before everything else comes trust. Fukuyama has done a lot of work in analyzing the catalytic countries of Western Europe and some Asian and non-Asian countries in which trust was a key role in building a powerful system.
2. Support (do code reviews, tests, briefings)
Besides trusting each other and creating a comfortable environment for working in a small team, you need to support each other. By supporting each other, we reduce the likelihood of error.
What I mean by this is focusing on the trivial things that get absolutely no attention when building startups in the early stages due to lack of time. This includes code reviews, which 90% of startups that I’ve spoken to don’t have, tests, joint briefings, along with business team briefings, product team briefings, and all-hands. I saw something quite atypical for the Russian market at Qonversion, when our CEO spoke about the business once a month, about the indicators, and shared all metrics. If we all see the same picture, we can all support each other.
3. Take more risks
Because of your small team, it’s important to increase your risks, to take more and more responsibility, and to be more and more proactive. This may increase the chance of mistakes, but remember, you are trusted, and you’ll be supported. Take risks.
4. Build the culture from day one
When it comes to all of this, you have to keep in mind that a startup’s culture needs to be developed from day one. This is often forgotten about because of the rapid growth context where tons of features need to be pumped out in order to make those millions. The culture of a team can always assume a shape that you won’t like, and by then it’ll be quite difficult to change it. Or there won’t be any culture altogether.
5. Be tolerant of mistakes, but avoid repeating them
When you create an environment where people grow quickly and take on more responsibilities, you have to be tolerant of mistakes. Being tolerant of mistakes means that you can’t reprimand people, you can’t hold people accountable for mistakes, and you can’t say, “What, you couldn’t have at least checked the code before releasing it?” That doesn’t mean, however, that we should encourage mistakes.
Another rule which comes from trying to fix bugs faster and being tolerant is that every bug you fix in a startup paves the way for a new bug, and this new bug helps you grow faster.
You need to communicate a lot. Small teams and startups often, due to time constraints, neglect the classic approaches that many people in corporations are familiar with – one-on-one sessions, joint events, and informal communication to name a few. In part, I can relate to this approach: in an uncertain environment, when a startup needs to focus on survival, it becomes quite difficult to devote so much time to team communication.
If you do end up surviving, you could very well end up with a group of people isolated from each other. In the future, you’d have to break that structure and build something fresh, something bigger than the product you have. The transactional model of communication won’t work, because companies and products are built by people in close-knit quarters.
Finally, I’d like to leave this interesting fact: until 2012, Facebook was a large monolith with a binary of about two gigabytes. This binary would take 15 minutes to build and 15 minutes more to release. That didn’t stop Facebook from becoming one of the fastest-growing startups, having done an IPO by this time, and further rebuilding itself. Airbnb, on the other hand, quickly made an MVP and then rebuilt its system in a super methodical and systematic way. This goes back to the premise that there aren’t any right or wrong approaches, we just may not always be paying attention to what’s needed in a startup.
In conclusion, I’d like to once again emphasize the importance of being aware of your approach. To some extent, approach determines outcome. Just as our awareness in life determines our relationships with people, the awareness of your approach and your attitude to the product will determine its quality. You have to know exactly when the code base you’re hammering away at needs to get tossed, or when it’s worth putting more time into developing a component.
The ability to switch thought paradigms is also important – it’s what determines the flexibility of both the project and your team. Rapid growth means rapid challenges and a change of context, and this is a quality you should try to master from the very beginning.