I’ve worked with many tech startups over the years. By and large there has always been one overriding factor that has caused tech startups to falter — trying to build their application to handle too much traffic upfront.

The goal of every tech entrepreneur is for everyone in the country to use their next product. Everyone is going to make the next star application, like Facebook. In order to accomplish this, tech entrepreneurs give a command to their tech team that is probably their worst mistake: “Make the application able to scale to millions of users.”

That might sound like a reasonable request, but I can assure you that it is absolutely the worst possible plan of attack. Programming legend Donald Knuth once said, “Premature optimization is the root of all evil (or at least most of it) in computer programming.”

Why is this?

Optimization — whether making code faster or more scalable (two separate, but related, ideas in optimization) — does several things. First, and most obvious, it takes time. That may sound obvious, but think of this: Any time you spend making your application more scalable is time you aren’t spending adding features, fixing bugs, or figuring out how your users can use your application better. In the early stages, those are the most important things. 

Unless you have a marketing budget of eight figures or better, chances are that you aren’t going to have the entire world knocking down the door of your application (at least at the official launch). What will cause your app to grow is word of mouth. That only happens if you have tight features, great usability, and zero bugs. If you took time out of your schedule to make sure your app could scale to 100,000 concurrent users on the first day, you wasted your time.

The second issue is deeper and much harder to see at first glance. When you optimize your code, you are usually cementing it in place. That is, when you write code, on the first pass, you write it in the easiest way that is most in line with the standard practices of the system (after all, that’s what the system is pulling you to do). When you optimize, you have to think about how each piece of the system can be altered in order to support the most common ways of working. You have to redesign each piece in order to have the optimal communication paths.

This may sound great, and it may sound like I’m re-iterating the “time” argument. However, what is actually happening here is that you are cementing your application’s architecture, and, by extension, its features. That is, if you redesign your application’s architecture so that a certain set of functions are maximally efficient, what happens if those aren’t the features that users are interested in? What if it turns out that those features are relatively unused, and some new feature comes in? 

If a lot of application architecture is wrapped around making those other features efficient, it winds up meaning that your new features not only have to be built, but they have to be built in such a way as to work around your software architecture. The goal of a software architecture is to facilitate future software developments, but, with premature optimization, software architecture quickly switches from friend to enemy. 

In order to optimize, you often have to bake features into the infrastructure. Then, if you want to remove them, you have to re-architect the whole application. It’s worse than rewriting, because you have to do it quickly (you’re a new startup) while the application is still in-place. This leaves a huge mess in the code, and winds up taking years (or longer) to really clean up. Sometimes, the vestiges of these unfortunate premature optimizations are never fully excised.

Here’s the deal — as a new entrepreneur you won’t make it to 100,000 users (concurrent or otherwise) unless the product works well for your customers. And, trust me, your first version won’t. If you invest too many resources in getting ready for the 100,000 users instead of being nimble enough to adapt to customer needs, you will find yourself struggling with your technology department and you likely won’t even understand why. Features that took minutes to implement in the early stages will turn into days, weeks, or months once your programmers have to work around your “optimization” criteria.

That isn’t to say that it is never time to optimize. There might even be some minor optimizations that you can make. The big stuff, however, needs to wait. When it is time, you will know it, and by then, you will have the resources to do it well, a product that is worth the effort, and a feature set which is worth cementing in stone.