You're Building for a Scale You'll Never Reach.

At some point in almost every side project, and more than a few real ones, someone says it. 'We should design this to handle millions of users.' The project has twelve. The architecture discussion that follows costs a week, produces a document, and results in an abstraction layer that nobody ever needs to justify because the scale never comes.

What premature scale actually costs

It's not just time. It's complexity that gets baked in permanently. Abstractions that made sense in a hypothetical world where you're serving ten million requests a day. Event queues for workloads that could run synchronously in milliseconds. Microservices for a team of three. Each decision feels defensible in isolation. Collectively, they turn a simple product into a distributed system that nobody fully understands, and that costs twice as much to change as it should.

The honest question you need to ask

When you're about to design for scale, ask: what is the actual problem I'm solving right now? Not in a year, not if everything goes perfectly — right now, with the users I have, the team I have, the data I have. Most of the time, the answer is embarrassingly simple compared to the solution being proposed. That gap is where over-engineering lives.

The complexity you add today is the complexity your team will maintain forever.

— Zaid Maraqa

When scale actually matters

This isn't an argument for building fragile things. There are decisions that genuinely are hard to reverse — your data model, your API contract, how you handle auth. These deserve careful thought early, because migrating them later is painful. But those are architectural seams, not scale problems. You can design clean seams without building for millions of users before you have a hundred.

The rule that actually works

Build for the next order of magnitude, not ten orders ahead. If you have a hundred users, design something that could handle a thousand without a rewrite. Not a million. When you hit a thousand, you'll know things you don't know now — about your actual bottlenecks, your real traffic patterns, what your users actually do. Design with that information, not without it. The engineers who get this right aren't the ones who saw the future. They're the ones who built something that was easy to change when the future arrived.