How to handle early startup technical debt (or just avoid it entirely)

All early startups share the same first goal. No matter which sector you’re aiming to disrupt, and no matter what groundbreaking new product or service you plan to disrupt it with, your prime directive is Get to MVP. Fast. After all, until you have something that people are willing to buy, your startup is really only an idea, not a company.

The pressure is on to launch your product or service as fast as possible and so embracing easy, “right enough for now” technical solutions makes sense in the early chaos of startup life. But as you start to find success — once you’ve built and launched that first crucial offering and customers start calling, once you begin hiring more teams to grow both your product and the organization that supports it — the limitations of your initial technical decisions are going to make themselves known. 

And, to be honest, so long as your org is small and your workloads stay relatively low, almost any application architecture will suffice. So long as performance is adequate under normal loads, startups can happily prototype and build out user-facing features in the race to reach product-market fit. You can usually keep on riding this pony into the early launch phase, too,  since most systems can consistently handle processing requests with reasonably low latency. 

But you are planning to succeed, right? 

The idea of course is for your product/service’s high utility value and cool features to bring a stampede of users, who bring more requests to handle and more data to manage. Eventually, you reach a tipping point where design decisions that made sense under light loads are now looking a lot like technical debt. 

The problem

Remember two years ago, spring 2020, when online retailers and government unemployment sites around the world buckled under unprecedented pandemic panic loads? Those were extreme circumstances, but the point is that you can’t predict when loads will surge. Even under “normal” conditions (whatever that means anymore), success equals steadily growing request loads, which means eventually latencies will also grow. 

As your go-to-market product or service becomes more feature rich, the application architecture underpinning it begins to reveal its limitations. This is the point where many startups find short-term technical convenience has become a blocker to long-term success. 

You’ll know you have hit the wall when it becomes hard to increment, modify and test rapidly, and your execution footprint becomes extremely heavyweight (probably because all your API implementations are running in the same application service).

via GIPHY

If you are an early-stage startup and that wall hasn’t yet arrived and things seem like they’re still working as needed, it’s tempting to just leave well enough alone. There is so much else to worry about, why fix something that isn’t actively broken? The problem being that, once business does take off and your systems have to perform under steady and increasing load, you simultaneously face a whole NEW set of next-phase startup problems. Now you’re worried about things like onboarding and retaining users, recruiting engineering talent, and building out a marketing department.

Even before that point, though, you run the risk of early success. A good problem to have, for sure. But what if your product/ service/app suddenly goes viral and everything else, both front and back ends, simply can’t keep up and eager customers meet slow or worse no access? What should be your best day suddenly becomes your worst.

The solution

The great thing about being a startup is that you can build whatever you please, however you please. If you are just starting up your startup, you have the opportunity to architect for inherent growth. If you are further along in the startup lifecycle, well, the time will come when you will likely need to make some changes to the technical path of least resistance taken in your innocent early days.

In either scenario the solution is the same: distributed architecture. Think of this as an internet-facing system composed from communicating services and distributed databases. Distributed systems are more complex to initially design and implement than most startups want (or, honestly, even need) in the very beginning. Once that initial work is invested, however, they are much simpler  to grow — to both scale up vertically and scale out horizontally, in pace with how your business grows. 

They also make it possible to scale down system capacity when not in use, to reduce costs. Think about Netflix: in any place on the planet, a lot more people are streaming Netflix at 9 pm local than at 5 am. Scaling down resources during times of lower load saves the cost of running the processing nodes, with the environmental side benefit of reducing data center power consumption.

Fortunately, increasingly powerful PaaS and IaaS solutions offer the advantages of distributed architecture while handling the complexity for you. There are important considerations that go into choosing these pieces of this “forever” stack that can grow flexibly along with your startup. As your next step, read our guide to distributed startup application architecture