We’ve all been there. You are building a new project, and you want to do everything "the right way." You follow the tutorials, you look at the enterprise-grade architectures, and you end up building a monster before you even have your first 20 users.
I made that mistake...
The "Golden" Architecture (The Mistake)
When I first launched my Laravel e-commerce app, I went all-in on AWS. I wanted reliability, low latency for LATAM, and scalability. My stack looked like this:
- Compute: EC2 (t3.large)
- Database: AWS RDS (Managed MySQL)
- Cache: Redis via Upstash
- Storage: S3 for images
- Region: São Paulo (sa-east-1) to keep it close to home.
On paper, this was the "correct" way to deploy a professional web app. In reality? It was a financial drain. I was paying for an infrastructure that could handle thousands of concurrent users while I was barely seeing 10 visits a day.
The AWS "best practices" are great for companies with VC funding or massive traffic. For an indie dev or a startup in its early stages, over-engineering is a silent killer.
The Switch: Back to Basics
I decided to stop following the hype and start following my wallet. I moved everything—the App, MySQL, and Redis—to a single server on Hetzner.
- Cost: 3x cheaper than the AWS setup.
- Performance: Virtually the same for the end-user.
- Maintenance: Significantly easier. One server, one config.
Before:
After:
"But it won't scale!"
I can already hear the comments: "What about the single point of failure?" "What about the bottleneck?" "That won't scale to a million users!"
You are right. It won't. And that’s perfectly fine.
Getting from 10 users to 5,000 daily active users is a monumental task. Most projects never reach that point. If you are lucky enough to hit those numbers, that is when you worry about scaling. Until then, your only priority should be staying alive and keeping your costs low.
The Takeaway: Just Ship It (Simply)
- Don't let infrastructure be the reason you quit.
- Keep it simple.
- Deploy on a cheap VPS.
- Focus on your code and your users.
- Upgrade only when the demand forces you to.
Scaling is a "good" problem to have. Don't try to solve "good" problems before you even have customers.
Top comments (1)
Really relatable. I’ve seen this exact pattern many times—teams optimizing for scale before they even have users.
In one of my previous projects, we also started with a “perfect” cloud setup (Kubernetes, autoscaling, managed services), and ended up spending more time managing infra than building product. Eventually moved to a much simpler setup and it made a huge difference.
Curious—at what point would you consider moving back to a more distributed setup? What signals would you look for?