Stop building for your first million users when you don’t have 10

I just told a founder to fire his CTO. Sounds harsh?

Their startup has zero users. Not one. Not even the founder’s mom has signed up. Yet their CTO wanted to build infrastructure capable of handling 115 simultaneous users.

Let me break down that math: 115 simultaneous users translates to roughly 662,400 daily active users, or nearly 20 million monthly users. That’s like having every Snapchat user in the UK on your app on launch day.

The conversation went like this:

Founder: “My CTO says we need enterprise-grade infrastructure.”

CTO’s requirements: “Must handle massive scale from launch. What happens with 115 simultaneous logins? We need 10 layers of microservices.”

Zero wireframes. Zero customer interviews. Zero evidence anyone wants this product. Just architectural astronaut engineering.

As someone who’s spent over two decades working with startups as a fractional CTO, I keep a depressing list: 31 dead startups with a combined burn of $12.5 million. Same cause of death every single time: over-architecting for problems they’d never have while ignoring the problems staring them in the face.

The million-user delusion is killing startups

I’ve watched this movie too many times. The playbook never changes:

The CTO spends six months building “scalable architecture.” They incinerate runway on AWS bills for empty servers. They finally launch to… tumbleweeds. Then they point fingers at “market conditions” and shut down with beautiful, scalable architecture serving exactly zero humans.

Meanwhile, scrappy teams with ugly MVPs built by interns steal customers because they focused on solving actual problems.

Just last year, I worked with a healthcare startup burning $28,000 monthly on infrastructure costs for 12 beta users. Fifteen microservices. Kubernetes. Apache Kafka. Two full-time DevOps engineers just to keep the lights on. Their architecture diagram looked like a subway map of Tokyo.

“This is insane,” I told them. “You’re building for Netflix scale with a lemonade stand budget.”

The room went silent. The CTO’s face turned red.

“But we need to be ready to scale,” he protested.

“You need to survive first,” I replied. “You have nine months of runway. You’ll be dead before you need a second server.”

The numbers don’t lie. Stack Overflow served millions of users on just two servers its first year. WhatsApp handled 450 million users with 32 engineers. Instagram sold for $1 billion with 13 employees.

This healthcare startup had more microservices than customers. Three-hour deployments. Engineers spending 80% of their time fixing infrastructure instead of talking to users.

Today, after consolidating to a monolith and cutting infrastructure costs by 90%, they’re at $275,000 ARR with 120 paying customers. Still running on that “simple” architecture, the CTO initially resisted.

Why smart people make terrible early-stage decisions

The root of this problem isn’t technical incompetence. It’s a fundamental misunderstanding of what early-stage companies need to survive.

I recently had another conversation that crystallized this. A CEO wanted his team to switch to TypeScript in the middle of their third MVP iteration, with mounting time and budget pressure.

CEO: “I want TypeScript. It’s what everyone uses.”

Me: “Why?”

CEO: “It’s better. It’s what I want. Deal with it. I’m paying you.”

Me: “Can I be blunt? You didn’t hire us to build ‘perfect’ code you love. You hired us to survive. Test assumptions quickly, get to market fast and focus on what matters now, not type safety.”

After some tense back-and-forth, we stayed with JavaScript. The results speak for themselves:

• Launch in seven weeks instead of 10-11 with TypeScript
• First paying customer after two weeks
• Three rapid user-driven iterations
• A pivot at four months that saved six months of development
• $500,000 funding round thanks to fast traction

Eight months later, they’re finally seeing the need for TypeScript. But by then, they had revenue, users and validation: the foundation needed to make smart scaling decisions.

The psychological trap is that experienced engineers often come from environments where scale, reliability and perfect architecture matter. When they join startups, they bring those same instincts to completely different problems.

At Google or Netflix, over-engineering might be prudent. At a pre-revenue startup, it’s financial suicide.

The pragmatic path to sustainable growth

Here’s what I tell every startup CTO: your job isn’t to build impressive architecture. It’s to help the company survive long enough to discover what users actually want.

Smart early-stage CTOs don’t architect for fantasy millions. They build to discover what users need, then scale when they’re drowning in demand.

The companies that obsess over automation and perfect architecture too early often miss what customers actually need. Your first 100 customers don’t care if your process is scalable — they care if it works.

I’ve learned this lesson by watching successful companies do the exact opposite of what we’re taught:

• Airbnb founders spent weekends taking professional photos of listings when they were making $200 per week, split between three founders
• DoorDash founders personally delivered their first 100 orders
• Reddit’s founding team posted content under different usernames to make the site look populated
• Diapers.com founders bought diapers at Costco and sold them at a loss just to test demand

These companies understood something crucial: you can’t optimize your way to product-market fit. You have to earn it through direct contact with real users and real problems.

The most dangerous person at your startup is a feature-obsessed founder or a CTO building for imaginary scale, not a bad engineer. I’ve personally watched that mindset bleed a $6.2 million-funded startup dry.

Building for ten, not ten million

My advice to early-stage companies is radically simple:

• Build the smallest thing that solves a real problem. If you’re not a little embarrassed by how bare-bones your launch feels, you’re shipping too late.
• Focus on three metrics: Are customers happy? Are you spending less than $1,000 on infrastructure? Can you deploy in under 10 minutes?
• Hire for pragmatism, not prestige. I will never hire ex-FAANG engineers in the early days of a venture. My experience tells me we’d drown in over-engineering before finding product-market fit. Early-stage startups need builders who can ship fast and iterate based on real feedback.
• Measure runway, not architecture complexity. Every unnecessary microservice brings you closer to death. Every hour spent on “perfect” code instead of customer conversations is a missed opportunity to learn something vital.

The healthcare startup I mentioned earlier learned this the hard way. After months of architectural complexity, they discovered their users didn’t want half the features they’d built. The real breakthrough came from a simple workflow change that took two days to implement.

Sometimes the best technical decision is choosing not to be technical. Early-stage startups don’t die from lack of Kubernetes; they die from lack of customers.

Your early-stage CTO should be a pragmatist, not a perfectionist. Because learning beats scaling every single time.

Stop building for your first million users when you don’t have ten. Build for the ten you can get tomorrow, learn what they need, then scale when success forces your hand.

Your runway — and your startup’s life — depends on it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?