In 2011, Startup Genome partnered with Berkeley and Stanford to study 3,200 startups. They wanted to know why most fail.
The answer wasn't bad ideas. It wasn't lack of funding. It wasn't competition.
74% of startups that failed did so because of premature scaling. Adding complexity... infrastructure, features, team size, process... before finding product-market fit. The same study found that failed startups wrote 3.4x more code before product-market fit than successful ones.
Let that sit for a second. The teams that survived wrote less code and used simpler architectures. The ones that failed were busy building platforms.
The Conference Talk Problem
Every conference talk, every trending repo, every "modern stack" blog post pushes you toward complexity. GraphQL. Microservices. Event-driven architecture. Server components nested inside client components wrapped in suspense boundaries.
Most of it is engineering for problems you don't have yet.
Dan McKinley... former principal engineer at Etsy... wrote about this in 2015, and the framework has only aged better. Every engineering team gets roughly three "innovation tokens." Chances to use new, unproven technology. Spend them on your product differentiator... not on your web framework, your database, or your deployment pipeline.
If your product's innovation is a novel AI feature, that's where the token goes. Your REST API doesn't need one.
Companies That Started Boring
These aren't hypotheticals.
Shopify runs a Rails modular monolith. In 2024, it handled 173 billion requests on Black Friday weekend. Not microservices. Not a custom framework. Rails. They've refined the architecture over 18 years, but the foundation never changed.
GitHub ran a Rails monolith for 12 years. They didn't start extracting services until they had 1,000 engineers in 2020. One thousand engineers and they were still on a monolith. When they finally extracted services, they did it selectively... not because the monolith couldn't scale, but because the team couldn't coordinate within it anymore.
That's the actual scaling problem: people, not servers.
Stack Overflow ran on 9 on-premise servers for over a decade... a .NET monolith with SQL Server serving billions of page views. They were transparent about this because it contradicted everything the industry said about scaling. In 2025, they migrated to the cloud when their data center contract ended... but the architecture that got them there was deliberately boring for 15+ years.
WhatsApp handled 450 million active users with 32 engineers when Facebook acquired them for $19 billion. The entire engineering team was smaller than most Series A startups.
The Boring Stack Formula
If you're a solo developer or a small team building a SaaS product... here's what "boring" looks like in practice:
One server, two apps. A backend API and a frontend client. Not a service mesh. Not a message queue. Two processes talking over HTTP on the same machine.
A relational database. Your data is almost certainly relational. Users have organizations. Organizations have subscriptions. Subscriptions have invoices. PostgreSQL has handled this reliably for 25+ years. It supports JSON columns for the 5% of your data that's actually document-shaped.
Auth you didn't build yourself. Authentication is a solved problem. It's also one of the most dangerous things to roll your own. Session management, token rotation, OAuth flows, MFA, password hashing... every one of these has security implications that take years to get right. Use Clerk, or Auth0, or Supabase Auth. Your job is to build your product.
Not microservices. You don't have the team for microservices. Microservices are an organizational scaling pattern, not a technical one. They let large teams (50+ engineers) deploy independently. If your team fits in a room, microservices add network calls, deployment complexity, and distributed debugging without giving you anything in return.
REST, not GraphQL. GraphQL is a fine technology for large organizations with multiple frontend clients consuming the same API. If you have one frontend... REST endpoints with clear request/response contracts are simpler to build, simpler to debug, and simpler to cache. You can always add GraphQL later if you actually need it.
When You'll Outgrow This
You will. That's fine.
A single server running FastAPI and PostgreSQL handles 10,000+ concurrent users without straining. The bottleneck, when it comes, will be database queries... not the framework, not the architecture.
Add indexes. Add caching. Optimize the queries showing up in your slow query log. These are straightforward problems with straightforward solutions.
If you reach the point where a single server isn't enough... that's a good problem. It means your product works. People are using it. And by then, you'll have revenue, data, and context to make informed architecture decisions instead of guesses.
The 2026 Bonus
Here's something the Startup Genome study couldn't have predicted in 2011.
Well-documented, widely-used frameworks produce measurably better results with AI coding tools. Cursor, Copilot, and Claude Code all perform better with FastAPI than with a framework that shipped six months ago. The training data is deeper. The patterns are more consistent. The suggestions are more accurate.
Boring tech isn't just safer. In 2026, it's faster to build with.
Now Go Build Something
Your idea is the interesting part. Your users, your market, your product... that's where the interesting decisions live.
The database schema, the API framework, the deployment pipeline... those should be solved problems so you can focus on the unsolved ones.
I built The Unsexy Stack around this philosophy. FastAPI + Next.js 15 + PostgreSQL. Two apps, one server, 111 tests, 17 PDF guides. The foundation that gets out of your way so you can build the thing that matters.
But you don't need my boilerplate to apply this thinking. Pick the boring option. Write less code. Ship sooner. Your architecture doesn't need to be interesting. Your product does.
I'm Alex Mayhew, a solo developer on Cape Cod. I write about engineering decisions that prioritize shipping over impressing. Find me on LinkedIn and GitHub.
Top comments (0)