Stop Over-Engineering: Just deploy your project 🛸

#webdev #software #infrastructure

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.