Building from zero to one is a different game than scaling from one to a hundred. The first is about finding something that works. The second is about making it hold up.
Most technical advice mixes these two up. Don't let it.
Phase one: finding it
At this stage there's really only one goal, find product-market fit. Everything else is secondary.
Ship fast, because learning speed is everything. Stay flexible, you will pivot. Minimize investment, most of this code gets thrown away anyway.
What actually matters here: can you ship a new feature in a day, can you change direction in a week, are you talking to real users daily?
What doesn't matter yet: scalability beyond what you need right now, perfect code quality, comprehensive tests, thorough documentation.
The right calls at this stage are usually a monolith, boring technology you already know the failure modes of, managed services so someone else handles ops, and as little infrastructure as you can get away with.
Phase two: making it reliable
You've found something that works. Now the job shifts to making it dependable.
Stability matters now, because users actually depend on you. Observability matters, so you understand what's happening when something breaks. Some process becomes necessary because coordination stops happening automatically.
Ask yourself: can you deploy without being scared, can you figure out problems quickly, can users actually rely on you?
This is the point to add monitoring before you need it, add testing for the paths that really matter, add documentation for onboarding, and formalize deployments so human error stops being the main cause of outages.
Phase three: handling real scale
Scale isn't just traffic anymore. It's team size, complexity, and coordination.
Now scalability, maintainability, and letting teams work in parallel actually matter.
Ask: can the system take 10x the load, can a new engineer contribute quickly, can teams work without stepping on each other?
This is when splitting into services starts making sense, when it's actually worth it, when the cost of coordinating inside a monolith exceeds the cost of the network calls between services. It's also when investing in developer experience starts compounding, and when formalizing architecture keeps everyone moving in the same direction instead of colliding.
The two mistakes that kill you
Building for scale you don't have yet. Microservices before product-market fit, Kubernetes before your first paying customer, complex caching before you actually need it. This kills startups before they even get going.
Not building the foundations when you finally do need them. Frequent outages, slow feature delivery, onboarding that takes months, every change breaking something else. This kills companies that were actually scaling.
And doing the right thing at the wrong time is still the wrong decision. Microservices are genuinely great, after product-market fit and team scale. Moving fast and breaking things is great, until real people depend on you not breaking things.
A rough checklist by stage
Before 10 customers: ship daily, talk to users, keep infrastructure minimal, and genuinely don't worry about scale yet.
Before 100 customers: basic monitoring, error tracking, automated deployments, and testing for the critical paths.
Before 1000 customers: comprehensive monitoring, an on-call rotation, load testing, and an actual disaster recovery plan.
Before 10,000 customers: a real platform team, an architecture review process, performance budgets, and capacity planning.
What scaling actually taught me
Match your investment to your actual stage, don't over-build and don't under-build either. Boring technology scales better, exciting technology tends to have exciting failure modes. People are the hardest thing to scale, technical scaling is genuinely the easier half. Good foundations compound, invest in developer experience early. And yes, premature optimization is real, but so is waiting too long to optimize.
FAQ
Should an early startup use microservices?
Almost never. Before product-market fit, a monolith is faster to build and change. This is one of the most common ways startups waste their early months.
When should a startup start caring about scale?
Roughly once real customers depend on you. Before 10 customers, don't worry about it. Before 100, add basic monitoring and automated deployments.
Scaling a technical team? Let's connect on LinkedIn.
