Premature optimization can sink your startup

Most software developers know the quote “…premature optimization is the root of all evil.” Almost all software developers agree with it. At the same time, I often see architectures and designs that throw the philosophy to the curb.

There will always be a debate about framework and tool choices. Tool A is better than B because it’s faster. Framework X is better than framework Y because it scales better.

Aside from the customer’s top problem, the only other problem we inherit on day 0 is maintainable software.

In the early stages of startups, I would consider these arguments premature optimization. The truth is, in the early days of a product, you don’t know what the latency or the scale needs to be. In fact, latency or scaling isn’t a problem at all when you have zero users. These problems don’t exist until they are proven to be a top customer or business problem.

This can result in unique and Frankenstein-like designs and architectures. We chose framework X because it scales the best. Now every technology we choose must scale. We chose tool A because it is the fastest. Now every tool we choose must be the fastest. Before you know it, your early-stage startup has a unique, hard-to-maintain application. And this occurred because you were solving problems that never existed.

Aside from the customer’s top problem, the only other problem we inherit on day 0 is maintainable software. From day 0 forward, we want fast iterations. We want to try many solutions to solve the customer’s problem. And we want this to be true for all the software developers.

In the early days of a project, we don’t know what problem we are solving. Instead, we have a lot of hypotheses. In this scenario, it makes sense not to optimize anything but maintainable software. We can’t architect or design the solution to a customer problem before it exists. Hopefully, at some point, we will have working solutions to customer problems. Once we reach this point, and we discover that the solution is too slow for the user, we can re-architect. This way, we’re designing with much more obvious constraints than day 0. This will almost always produce better architectures and designs.

In the early days, choose tech stack technologies for iteration speed and maintainability. Choose full-fledged frameworks. These kinds of frameworks have been around for many years. They’ve been in production for a long time. The team has resolved many bugs. They have documentation that works for broad audiences. They’ve solved a lot of problems like migrations, deployments, observability, etc.

If you read between the lines, you’ll see that Django and Rails fit this bill pretty well. These frameworks will allow your whole team to move fast. And for the most part, you can avoid premature optimization.

Most startups will not ever get to see the limits of these frameworks. They won’t need a greater scale than what the frameworks offer. They won’t need a lower latency than what the frameworks offer. And this is a good thing. These startups will have shed complexity for maintainability. If your company hits the limits of these frameworks, you’ll be well suited to solve the problem. At this point, you can evolve your architecture/design to solve a specific problem.