Rapid scaling can ruin your startup — so fix these technical problems now

In the grand scheme of things, everything has been going perfectly to plan. Your product or service launch has been a success, your company has started to gain lots of traction, and as a result your user base has begun to grow rapidly.

But then, as your 100 daily users suddenly become 100,000 … crash! Your platform slows to a snail pace, your app turns super glitchy and instead of basking in your newfound success, you end up frantically firefighting to keep your platform online under increased demand. After all, the plan was to make your user base explode, not your servers!

According to the Startup Genome Report, 74 percent of startups fail because of not being prepared to scale or scaling prematurely. A product or service scaling should be a euphoric moment for startup founders. Unfortunately, though, if teams have not thought ahead and prepared for their user base increasing rapidly, what should be a dream experience can actually turn into a nightmare.

So, with this in mind, here are three hidden danger zones which can cause problems if a startup’s product or service starts scaling very quickly:

1. Being too reliant on outsourced developers

In their early stages, startups are often forced to hire skeleton teams of developers and rely heavily on outsourced developers for essential sprints. With highly paid developers being in such high demand — and knowing it — most startups simply do not have the financial resources to hire large in-house development teams from the outset.

However, this reliance on outsourced developers can lead to valuation problems down the line, as smart investors tend to be just as interested in the jockey (the in-house talent) as the horse (the product). This can also lead to technical problems emerging when a spike in traction and visibility leads to a rapid growth of the user base, too.

When a user base starts to spike, your whole development team needs to be on 24/7 firefighting mode to respond to any glitches or outages at the speed of light. Every second your platform is down adds to the risk of potential long-term clients losing interest and disappearing into the sunset forever.

It’s extremely hard to ensure this level of reactivity when dealing with outsourced developers, especially if they are based in a different geographic zone — and thus timezone — than the rest of the company and its users.

However, at the same time, there is no silver bullet response to the developer ‘chicken and egg’ issue either. Based on my personal experiences, I would recommend that startups prioritize bringing on a small, in-house development team for all core platform engineering tasks, even if this means cutting back on other things like fancy open plan offices, and craft beer Fridays.

Remember that there are other ways to attract high-quality, loyal team members who won’t jump ship at the first better offer than simply throwing cash at them. Try offering generous equity deals to core team members, and offering interesting, engaging projects which will allow your core team of developers to challenge themselves, while working on a tool that will serve millions of people around the world.

2. Failing to calculate the costs of scaling third party services

Whether it be accepting payments via Stripe, receiving calls via Twilio, using mapping functions via Google Maps, or authenticating a login via Auth0, startups have jumped into the API era with two feet.

However, while the ability to tap into existing services rather than having to worry about developing your own versions in-house is great, over-reliance on these third party service providers can end up being extremely expensive when your user base starts to scale. And can be completely devastating if platforms — like Instagram — cut access via APIs.

Nowadays, the ‘on demand’ consumer trend is booming, meaning that lots of products — from taxi apps, to dating or delivery services — are using location-based tools, which rely on third party mapping services like Google Maps or MapBox for GPS functions. However, while these services are mostly free at first, and affordable for startups with a small number of users, when these services are receiving tens of thousands of API requests a day, these costs can really start adding up.

Just to put this into perspective, global products like Uber are paying roughly $5 million a year to use Mapbox mapping functions. Mapping tools tend to have complicated API structures, charging startups based on how many users are using the GPS functions, how many API requests are rendering the map, and other functions such as route calculation. Since all of these different elements are charged individually, it can be hard for startups to predict costs when user bases scale.

As such, it’s always good for startups to ‘assume for the best’ and overestimate rather than underestimate when calculating potential expenditures on third party services, and work out at an early stage if they can afford to use them. If the high-end price predictions are not feasible, then it makes sense to choose from ‘up and coming’ services that are more affordable at scale. In the case of mapping services for example, MapFit or CityMapping would be more affordable in the long term than Google Maps or MapBox.

It is also worth calculating whether the development costs of building a solution in-house would be less overall than paying for third party services at scale. Another option would be to build on top of a more affordable solution.

For example, for maps, OpenStreetMap paired with Leaflet or another open source code mapping service would be an option, but this would pose more of a challenge from a development perspective, as the startup would need to develop routing systems in-house.

However, while these options put more of a strain on developers, they give startups more control of their own data.

3. Underestimate the challenges (and costs) of scaling infrastructure

While the CEO is undoubtedly going to be skipping with glee when the user base starts spiking, the CTO is likely to be looking a little worried, and their first concern is probably going to be your hosting platform.

While services like AWS and Azure are designed to facilitate companies scaling, and offer a range of ‘off the shelf’ services like machine learning AI, they come at a cost.

And according to Red Hat CEO Jim Whitehurst, these public cloud services are ‘obscenely expensive’ at scale, especially if using compute-heavy services like AI. As such, while many companies will not have the resources to build their own data centers and servers, it is advisable to check out a range of platforms such as Heroku and Lambda rather than automatically going with one of the ‘Big Five.’

The next headache is most likely going to be your company’s databases. While NoSQL databases like MongoDB and Cassandra are easier to scale, SQL databases like MySQL, PostgresQL, and Oracle can be trickier. However, regardless of what database you’re using, it is going to pose a lot of work, and will require the expertise of database engineers which are in high demand, and expensive to hire.

But at the end of the day, there is no getting past it: you need to have a solid infrastructure to be scalable. If your infrastructure is not strong enough, and your tool or app suddenly receives a lot of traffic, the servers won’t be able to service or provide access to a website, and this will affect the over-performance of the platforms.

The ‘quick fix’ is to choose a fully managed database provider like Google’s Firebase, MongoDB mLab, or Amazon RDS; however, like with ‘off the shelf’ cloud solutions, these will be expensive. But for those who want to keep things in-house, I would recommend scaling horizontally harnessing cloud services.

If you decide to manage your infrastructure inhouse, it’s always important to have a plan in place to deal with a potential flood of requests, so that your technicians know exactly the capacity of your servers, and are ready to bring more online quickly in the case of a surge in users. It’s also worth training for all eventualities, for example, if your servers go down during a surge so that your team can react in a calm and collected manner, when disaster strikes.

Opportunity often arises when least expected, and one of the challenges of running a business is responding to unexpected events in a calm, organized manner. If startups take the time to monitor metrics and traffic, then there should be warning signs that allow them to prepare for tsunamis of traffic at short notice.

However, the only ‘silver bullet’ response is to build your team, services and infrastructure in a strong, sustainable manner from day one, rather than making quick fixes and cutting corners, only to find yourself weighed down by mountains of technical debt. After all, the best way to avoid danger zones is to have them mapped on your product roadmap from the very beginning.