If you’re in a technical role at a startup, you know that avoiding tech debt isn’t as easy as it sounds.
Imagine walking into this: « About 4 million lines of PHP code, written by underpaid, sometimes not well-meaning, freelancers and students over the span of 8 years. The CEO wrote a large part, but stopped learning new techniques around 2004. » That’s how bad tech debt can get when a startup is run without considering that all of those messy shortcuts will eventually have to get cleaned up. If you’re in a technical role at a startup, though, you know that avoiding tech debt isn’t as easy as it sounds. Startups often have a lot of development milestones to hit in very little time. Getting a startup to MVP with limited personnel and budget sometimes requires cutting a few corners, knowing you’ll have to do some refactoring in the future. But moderation is important. When you’re taking on tech debt, you’re building a mountain that you’ll have to climb before your company can scale. All the engineering time you’re saving now will have to be paid back — often with interest. Many developers that have worked on projects with significant tech debt have stories like this: I’ve worked in a couple of large and messy codebases where we undertook a big refactor, it took longer than expected and then the resources were pulled to other things before it was completed. Net result: an even larger, messier and harder to understand codebase! In other words, when tech debt gets too big, fixing it becomes very tricky even when you have a lot of resources to throw at the problem. For startups, the best approach is to avoid taking on any unnecessary tech debt, so let’s take a look at six things startups can do to minimize or eliminate the tech debt you’ll have to pay back before you can scale. This advice may sound obvious, but following it can be challenging. It’s not always obvious what debt you need. Building a startup almost always requires making some compromises in the early days, but as tools and technologies change and evolve, it can be difficult to figure out which compromises you actually need to make. Consider, for example, the transactional database. Just a few years ago, startups had to make a difficult choice, and one that unavoidably involved compromise: do you opt for a NoSQL database that’ll scale quickly and easily, and deal with the potential consistency problems and potentially higher costs now? Or, do you go for something like PostgreSQL that’ll be reliable, easy, and free for your developers to work with now, but probably challenging to scale in the future? Neither of these options is ideal; the NoSQL approach can come with unpleasant down-the-road problems such as dirty reads, phantom reads, write skew, etc. But the Postgres approach is also taking on a kind of debt, as it’ll have to be manually scaled later. As education startup Kami learned during the pandemic, scaling Postgres can be painful: « We knew how complicated it would have been to stay with Postgres and set up sharding. There would have been a constant drag of managing multiple shards of data. No one on our team wanted to go through that manual labor. And even if we did set up sharding, we weren’t going to be able to grow our business 10x. » Today, though, it’s possible to avoid taking on a lot of tech debt simply by opting for the right stack — although what constitutes « right » will depend quite a bit on what you’re building and what you’re already familiar with. In almost any stack, though, no-compromise options allow startups to get the best of both worlds. The transactional database is just one part of your stack, of course, but similar solutions now exist for almost every layer. The business logic of your application, for example, can be moved to a cloud-based serverless service such as AWS Lambda, Google Cloud Functions, or Azure Serverless Functions, allowing for nearly infinite scalability without requiring much of an up-front investment in terms of time or money. It is critical, then, for startups to be aware of their options. Compromises that companies like Kami were forced to make may now be completely avoidable thanks to new tools.
