A Beginner's Guide to Not Overengineering Everything
Look, I get it. Heroku is ancient technology that Safesforce bought and let rust away in the driveway. It's 2025, and there are sexier options out there. Railway is honestly better. Vercel is fantastic. Convex is doing some really cool stuff. But you know what? That's not the point.
The point is that your 5-person B2B SaaS startup that's handling maybe 3 requests per second on a busy day has absolutely no business spending weeks architecting some complex Kubernetes cluster on AWS.
Part 1: The Seduction of Complexity
The Infrastructure Delusion
Here's what I see happening over and over again:
A small team gets together. They have a solid idea for a B2B product. They've talked to a few potential customers. Things are looking promising. And then... they spend the next two months building "scalable infrastructure."
They're Dockerizing their workflow. They're writing Terraform scripts. They're setting up service meshes. They're implementing blue-green deployments. They're building world-class CI/CD pipelines.
Meanwhile, they have exactly zero real paying customers.
You know why this keeps happening? Because there's an entire ecosystem that profits from your infrastructure anxiety. It's a self-perpetuating cycle fueled by a few key factors:
- •The "High Scalability" Canon: Engineers read blogs like High Scalability, see the incredible architectures of Netflix and Google, and aspire to build the same. The problem? They're reading the wrong playbook. Those companies have problems you don't.
- •The Shiny New Tool Syndrome: The market is flooded with cool-ass products built for massive scale—serverless databases, global edge functions, distributed message queues. These tools are genuinely impressive, and engineers are naturally enticed to use them. It's resume-driven development at its finest.
- •The Migration Myth: The unspoken truth is that very few companies with existing, profitable products are willing to undertake the massive risk and expense of migrating to these new, unproven platforms. So, who do these toolmakers market to? You. The pre-product-market-fit startup with more ambition than users.
- •The VC-Fueled Hype Cycle: Venture capitalists pour money into these infrastructure startups, who then spend that money on marketing to convince other VC-backed startups that they need to build for "web scale" from day one.
The result is a market with a thousand solutions for a problem only a dozen companies actually have. And you're paying the price in complexity and lost time.
Meanwhile, some guy in his basement is building a profitable business on a $20/month Digital Ocean droplet.
Part 2: The Flawed Logic
"But What If We Need to Scale?"
This is the question that keeps founders up at night, justifying their premature optimization. But let me ask you this: what if you actually succeed and need to scale?
Congrats! You have a problem 99% of startups would kill for. You know what you do then? You hire people who actually know infrastructure. Or you migrate. With all that revenue you're making from your successful product.
Scaling problems are good problems. They mean people actually want what you're building. The fear of scaling shouldn't paralyze you into building for a future that may never come. It should motivate you to build something people want first.
"But We're Different"
No, you're not.
You're not going to be the next unicorn that needs to handle Facebook-scale traffic on day one. You're not going to have a viral launch that brings down your servers. You're not going to wake up to find that TechCrunch has driven a million users to your landing page.
You know what you're actually going to wake up to? The same 17 beta users you had yesterday. Maybe 18 if your mom finally signed up like she promised.
The Graveyard of Perfect Infrastructure
You've seen it a hundred times. Startups with beautiful infrastructure and zero customers. Their code is written exclusively in Rust. Their Kubernetes clusters are immaculate. Their deployment pipelines are works of art. Their monitoring dashboards look like mission control at NASA.
They'll never need any of it. They'll never have growth or cashflow.
They'll tell you stories about how they're "ready to scale." They'll show you their load testing results. They'll explain their microservices architecture with the enthusiasm of a teenager showing off their new gaming PC.
Six months later, they're updating their LinkedIn profiles.
Part 3: The Brutal Reality
The Math Nobody Wants to Do
Here's the really insane part. Sit down and actually do the math on your addressable market. Let's say you're building software for, I don't know, veterinary clinics. You somehow capture 100% of the market. Every single vet clinic in America is using your software. You IPO at a $30 billion valuation.
Guess what? You still wouldn't need more than one beefy Postgres box and maybe two read replicas for failover.
I'm not exaggerating. Run the numbers. How many vet clinics are there? How many transactions per day does each one generate? It's nothing. It's absolutely nothing compared to what a single modern database server can handle.
But here you are, pre-launch, architecting for "web scale."
Your Customers Don't Even Care
And here's the kicker - most B2B customers, especially in traditional industries, couldn't give less of a shit if your service goes down at 2 AM.
The dentist isn't scheduling appointments at midnight. The accounting firm isn't running payroll on Sunday. The law firm isn't filing briefs at 3 AM.
But you're over here building 99.999% uptime infrastructure with blue-green deployment and multi-region redundancy for customers who literally close their laptops at 5 PM and don't think about your software until tomorrow morning.
The Real Cost
It's not just about the AWS bill (though that's bad enough when you're pre-revenue). It's about something much more valuable: time.
Every hour you spend debugging why your Kubernetes pods aren't talking to each other is an hour you're not spending:
- •Talking to customers
- •Building features that customers actually want
- •Iterating on your product
- •Finding product-market fit
- •Making sales
You know, the stuff that actually determines whether your startup lives or dies.
The Uncomfortable Truth
Most startups fail because they build something nobody wants. Not because they couldn't scale to handle millions of users.
Your sophisticated infrastructure won't save you when you realize you've been building the wrong thing for six months. But those customer conversations you skipped? Those might have.
Part 4: The Simple Path to Success
What Success Actually Looks Like: Stories from the Trenches
You want to know what a successful early-stage startup's infrastructure looks like?
It's boring. It's embarrassingly simple. It's probably held together with some questionable bash scripts. Back in the day the deploy process for many of today's massive companies was literally "SSH in and pull from git." The monitoring is probably just a cron job that emails you if the site is down.
And it worked. It works because the founders spent their time making something people want instead of building a monument to their own engineering egos. Here are some examples:
Stack Overflow, the site every developer on Earth visits daily, ran for years on just 9 servers. Not nine thousand. Nine. They handled 10 million pageviews a day on hardware that cost less than a typical pre-launch startup's AWS bill.
Basecamp runs on a handful of powerful servers and has been profitable for years, serving millions of users. They famously wrote blog posts mocking the complexity of modern infrastructure while proving that a simple, powerful monolith can be incredibly effective.
Plenty of Fish was a top-10 website in the US, handling billions of pageviews on a single database server for years. The founder, Markus Frind, made $10 million a year in revenue while maintaining the entire site himself.
Pinboard, the bookmarking site, has been run by a single developer, Maciej Cegłowski, for over a decade. It's profitable and runs on a simple setup, while he regularly dunks on venture-backed startups with huge engineering teams and complex architectures.
Instagram started as Burbn, a check-in app built on a simple Django stack. When they pivoted to photo-sharing, they kept it dead simple. Basic AWS setup, PostgreSQL, and that's about it. They had 25,000 users on day one, a million users in two months, and sold to Facebook for $1 billion two years later. Their infrastructure at acquisition? 3 engineers managing a handful of servers.
Remember Diaspora? They were going to kill Facebook. They raised $200k on Kickstarter back when that was a lot of money. They spent months building a "federated" social network with a complex distributed architecture. They were so focused on the technical challenge of federation that they forgot to build something people actually wanted to use. Nobody remembers Diaspora.
Or take Groupon. You know what their initial "infrastructure" was? A WordPress blog. Not even kidding. They manually emailed PDFs to customers. They were doing billions in revenue before they built any real infrastructure. Because they focused on proving people wanted daily deals, not on building the perfect deal-delivery platform.
Park.io, the domain backordering service? One developer, runs on a couple of servers, makes millions in revenue. The founder regularly posts about keeping things simple while his competitors burn VC money on complex infrastructure.
Just Ship It
Pick a platform. Any platform. Heroku, Railway, Vercel, Render, Fly.io - I don't care. Pick one that lets you deploy with a git push and forget about it.
Yes, it'll cost more per unit of compute than raw AWS. You know what costs even more? Your time. Your opportunity cost. Your startup's life bleeding away while you're cosplaying as a DevOps engineer.
The Successful Startup Starter Pack
Here's everything you actually need:
- •A way to deploy code (git push heroku master)
- •A database (Postgres, always Postgres)
- •A way to send emails (whatever, SendGrid, who cares)
- •A way to accept payments (Stripe, done)
- •Error tracking (Sentry free tier)
That's it. That's literally it.
Everything else - EVERYTHING ELSE - is you avoiding the hard work of building something people want.
You want to know the dirty truth about why engineers do this? It's not about the technology. It's about fear.
Fear of shipping. Fear of talking to customers. Fear of finding out that nobody wants what you're building.
It's so much easier to spend another week perfecting your auto-scaling configuration than to cold-email potential customers and get rejected. It's so much more comfortable to debug Terraform scripts than to debug why nobody's signing up for your product.
Infrastructure is the perfect hiding place. You can always make it more "robust." You can always add another layer of abstraction. You can always find another best practice to implement. It feels like progress. It looks like work. But it's really just procrastination with a technical degree.
The Bottom Line
If you're reading this and feeling attacked, good. You should feel attacked.
Your job as an early-stage startup isn't to build the perfect infrastructure. It's to find out if anyone gives a shit about what you're building, as fast as humanly possible.
Every moment you spend arguing about whether to use EKS or ECS is a moment you're not spending asking your customers what problems they have. Every hour you spend debugging service mesh configuration is an hour you're not spending on product-market fit. Every day you spend on infrastructure is a day closer to running out of money.
While you're architecting for problems you don't have, your competitors are out there eating your lunch. They're not smarter than you. Their code isn't better than yours. They just understood something you didn't: nobody gives a fuck about your infrastructure.
Your customers don't care. Your investors don't care. The market doesn't care. You know who cares? Your ego.
You're not building the next Facebook. You're building a tool for plumbers, or lawyers, or whoever. They don't care about your infrastructure. They care about whether your product solves their problem.
So please, for the love of all that is holy, stop wasting time wrangling AWS. Stop pretending you're Google. Stop building for a scale you'll probably never reach.
Just fucking use Heroku. Or Railway. Or whatever.
Then go talk to your customers.
Full Disclosure: I have never actually just fucking used Heroku. My experience with automated deployments starts with Elastic Beanstalk and now I'm deep in serverless systems.
I have, however, built a state-of-the-art Kubernetes deployment for a 5-person startup, where we would have 100 req/sec even if we captured the entire $20 billion market, and our customers wouldn't care even if we had hours of downtime every weekend.