Premature Optimization: Building for Users You Do Not Have Yet

What it actually looks like

You can describe your architecture in detail. The failover story, the queue, why the cache sits where it does, what happens when a worker dies mid-job. It is a good design. You are right to be pleased with it.

You cannot describe your customer in the same detail. You could tell someone who they are in a sentence, maybe two, and the sentence has not changed in five months because nothing has happened to change it.

You spent last week making a code path faster. That path runs about eleven times a day, and it was not slow. You know both of those facts. You did it anyway, and it felt like the most productive week you had had in a while.

There is an abstraction layer between your application and a service provider, so you can swap the provider later. You have not chosen the second provider. You have not priced one. Nothing has ever suggested you will need one.

The demo is a week out and you are rewriting the data layer, because the current one "will not hold up." Hold up to what, exactly, is a question you have not put a number on — and you are a person who puts numbers on things.

And there is a specific relief in the work. You open the editor on the infrastructure problem and something in your chest settles. Compare that with how it feels to open the tab where you were supposed to write to twenty potential customers.

Who this happens to

This is common among engineers who came from somewhere the scale was real.

If you spent years at a company where a bad query took down a region, your instincts were built in an environment that punished exactly the thing you are now protecting against. Those instincts were correct there. They are not wrong now — they are early, which is a different problem and much harder to feel from the inside, because being early looks identical to being prepared.

It is common in founders who are uncomfortable with go-to-market work. Building is where you are competent and where the standards are yours. Selling is where you are a beginner in public. Given a day with both on the list, almost anyone walks toward the room where they are already good.

And it is common in people who take craft seriously — who have real opinions about how software should be built and have watched shortcuts turn into eighteen months of interest payments. That experience is worth something. It is also the exact belief that makes "build it properly first" impossible to argue with.

What sets it off

Look at what happened the day before you started the big infrastructure push.

Often it is a hard conversation with the market. A batch of outreach that got no replies. A call that went politely nowhere. A customer who said the thing about the price. Nothing catastrophic — just a few hours of evidence that the demand you are counting on has not shown itself yet. Infrastructure work is the most available way to stop feeling that.

Sometimes it is a story. A postmortem, a thread about a launch that fell over under load, a company that lost its moment because the servers melted. The story is true and it is about a company that already had the users. You imported the lesson and skipped the precondition.

And sometimes it is the launch itself approaching. What if it works. That thought is supposed to be motivating, and for a certain kind of careful person it is the opposite: it produces a vivid picture of failing publicly at scale, and a week of hardening is how you make the picture stop.

Underneath all three is one condition. On the customer side, your next step is vague and might be rejected. On the infrastructure side, your next step is crisp, entirely within your control, and no one can reject a database schema.

Why it keeps happening

The mechanism is a feedback loop you can close by yourself.

Infrastructure work has an honest, immediate reward: the test passes, the benchmark moves, the diagram gets simpler. You set the standard, you meet it, you know you met it. Customer work offers nothing like that. You send the email and wait. The signal is slow, noisy, and frequently a silence you have to interpret yourself. Of two available kinds of effort, one pays reliably in the currency of feeling competent and the other mostly does not.

Then there is the timing problem, which is the part that actually costs money. Scale problems are earned. They only exist when something is already working. By solving them in advance you are spending your scarcest resource — the months of runway you have left — defending against a future that has not agreed to arrive. If you are wrong about the demand, the infrastructure was free to build and worthless. If you are right about the demand, needing to rewrite for load is the best problem available to a founder, and you would have had the revenue to fund the rewrite.

There is also an information problem worth being blunt about. The knowledge of what will actually break under real load does not exist anywhere yet. It is not in a blog post and it is not derivable from your design. Real traffic produces it, and nothing else does. So the optimizing you are doing now is guessing — performed with the tools, the rigour and the confidence of measuring, which is what makes it so convincing.

And the framing seals it. This work is not procrastination in any form you would recognise, because it is real engineering, done well, on your own product. That is precisely why it works so well as avoidance. Nobody, including you, can call it a wasted week without sounding careless.

What actually helps

Put one question between you and the next architecture decision: is this a problem I have, or a problem I am imagining? Write it somewhere you cannot avoid seeing it, and answer it out loud before you open the editor. Most of the time the honest answer arrives instantly, and hearing yourself say it is enough.

Then give the imagined problem a number. At what point does the current version break — how many users, how many requests, how much data? Write the number down, and write today's number beside it. If today's number is a hundredth of the threshold, you have not made a judgment call; you have found out. Keep the pair of numbers in the repository so future-you can see when the trigger genuinely fires.

Build the smallest thing that works for the load you have, and log the trip-wire instead of the safeguard. A single machine, the simple query, the obvious approach — plus one alert that tells you when the assumption stops holding. That alert is worth more than the abstraction layer, costs an hour, and turns a guess into a thing that will tap you on the shoulder.

Move the customer step first, on the same day. Before the next infrastructure session, do the thing you have been putting off: send the twenty emails, book the call, publish the page. Not because the infrastructure is unimportant, but because doing it in that order is the only way to find out which of the two you were actually avoiding.

And let something break once, cheaply, while the stakes are small. A product that falls over at forty concurrent users teaches you more in one afternoon than a quarter of defensive design, and it teaches it about the real system rather than the imagined one. You are allowed to earn the problems of success before you solve them.