What "scale" actually means before you have users
Building for scale you don't have yet is its own kind of premature optimization.
Early-stage teams often over-invest in scalability for a scale they don't have yet, out of a reasonable fear of having to rebuild later. The irony is that this kind of premature scaling work usually slows down the process of getting to the users that would actually justify it.
The scale you actually need first
Before a product has meaningful traction, the scale that matters isn't concurrent users or requests per second — it's how fast the team can learn from real usage and change direction. Infrastructure decisions optimized for that kind of scale look very different from ones optimized for handling millions of users.
What's genuinely worth doing early
Not everything scale-related should wait — a data model that's roughly right, and boundaries that don't assume a single monolithic blob forever, are cheap to get right early and expensive to fix later. The distinction is between structural decisions and operational scale, and only the former deserves early attention.
Real scale problems are a good problem to have
When a product actually starts hitting real scale limits, that's usually a sign of success worth celebrating — and by then, there's real usage data to make informed decisions about what to optimize, instead of guessing at what future scale might look like.
- Early-stage scale is about learning speed, not requests per second.
- Get the data model and boundaries roughly right early — the rest can wait.
- Hitting real scale limits later is a good problem, informed by real data.
The support burden nobody budgets for at launch
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.