Do Not Build Without Reading This

How many times have you seen someone build a beautiful MVP with all the cloud bells and whistles… only for it to flop? The product had everything. Lambda functions are buzzing. API Gateway routes are neatly mapped out. Cognito user pools are locked down. Files in S3, served globally via CloudFront. Data in DynamoDB. Logs in CloudWatch. IAM policies are crafted like a government document. The architecture diagram looked like a subway map during rush hour. And yet, no one used it. Zero traffic. Zero users. Zero impact. The hard truth? You don’t need AWS to build something users love. The Overkill Problem in Startup Tech There’s a subtle poison running through the modern indie dev and startup ecosystem: overengineering. It usually starts innocently. You read a few posts on Hacker News. Watch a couple of YouTube videos from cloud influencers. Or scroll past a flashy architecture diagram on Twitter explaining how Company X uses 27 AWS services to serve cat memes at a global scale. And suddenly… your brain starts to think maybe my to-do list app should do the same. Spoiler alert: It shouldn’t. Unless you’re Netflix, Airbnb, or solving for millions of daily users out of the gate, you are wasting your time, money, and most critically, your focus. Most early-stage projects don’t fail because they couldn’t scale. They fail because they didn’t solve a real problem, had poor UX, or were never launched in the first place. AWS Isn’t the Problem. It’s Misuse of AWS. Let’s be clear. Amazon Web Services (AWS) is an incredible cloud platform. It’s robust, feature-rich, and can scale anything from a scrappy prototype to a planet-wide operation. But here’s the catch. You don’t need all that power right now. You don’t need 12 microservices communicating via SNS and SQS queues. You don’t need a separate Lambda for every single route. You don’t need to architect high availability across multiple AZs if no one has even signed up yet. Here’s what you need: USERS and a working PRODUCT with REAL FEEDBACK. Your customers don’t care if your backend runs on Kubernetes, Lambda, or a potato. They care about whether your product works, solves their problem, and is easy to use. Build Fast and Launch Faster Let’s boil it down. If you are a solo developer, an indie hacker, or a small team trying to ship a working product, this is all you probably need to start. A simple €5 to €20 per month virtual private server (VPS) from Hetzner, DigitalOcean, or Linode Docker Compose to run your app, database, cache, and background workers A basic Nginx or Caddy server to handle HTTPS and reverse proxy SSH access to deploy your application manually That’s it. You can run a real-world SaaS, dashboard, API, or internal tool on a single server for a long time. Let’s be honest: most MVPs will never outgrow that box. Not for months, maybe not ever. And if they do? That’s a good problem to have. You’ve earned the right to scale. The Illusion of Infinite Scale One of the biggest myths in the startup playbook is the obsession with scalability. Everywhere you look, there’s pressure to build for scale from day one. But here’s a better mantra: Build for survival first. Then scale. Optimizing for scale without users is like buying more frying pans when you don’t even have ingredients for the meal. Or renting out a stadium before anyone’s bought a ticket to your show. Spending weeks fine-tuning IAM policies, API permissions, and multi-region deployments before shipping version 0.1 is the ultimate form of procrastination disguised as productivity. When AWS Makes Sense Now, let’s be fair. AWS has its place. There are valid reasons to use it, just not for most MVPs. Here’s when AWS makes sense. You’re learning AWS for your cloud engineering or DevOps career. You want certification and hands-on practice. You have strict compliance or residency requirements. Your data must stay in a certain country, or you need specific cloud certifications. Your product is already scaling fast. You’ve validated the market and have high traffic or specialized infrastructure needs. You’re deeply invested in the AWS ecosystem. Your team has experience, or you’ve got legacy systems running there. In these cases, go for it. AWS is amazing when it’s needed. But most projects? They just don’t start there. And that’s okay. You can always migrate later. When your product has traction and revenue, you’ll know exactly what needs to scale, and why. How to Ship Without AWS Still want to launch something real? Want to avoid the rabbit hole of cloud certifications and YAML debugging sessions? Here’s how to get your project live, today: Write your application using a solid, battle-tested framework like Django, Rails, Express, or Flask. Use Docker Compose to define your services, your app, database (PostgreSQL, MySQL), a cache like Redis, and background workers if needed. Push your code via SSH to your VPS. Run docker com

May 7, 2025 - 12:13

How many times have you seen someone build a beautiful MVP with all the cloud bells and whistles… only for it to flop?

The product had everything. Lambda functions are buzzing. API Gateway routes are neatly mapped out. Cognito user pools are locked down. Files in S3, served globally via CloudFront. Data in DynamoDB. Logs in CloudWatch. IAM policies are crafted like a government document. The architecture diagram looked like a subway map during rush hour.

And yet, no one used it.

Zero traffic. Zero users. Zero impact.

The hard truth? You don’t need AWS to build something users love.

The Overkill Problem in Startup Tech

There’s a subtle poison running through the modern indie dev and startup ecosystem: overengineering.

It usually starts innocently. You read a few posts on Hacker News. Watch a couple of YouTube videos from cloud influencers. Or scroll past a flashy architecture diagram on Twitter explaining how Company X uses 27 AWS services to serve cat memes at a global scale.

And suddenly… your brain starts to think maybe my to-do list app should do the same.
Spoiler alert: It shouldn’t.

Unless you’re Netflix, Airbnb, or solving for millions of daily users out of the gate, you are wasting your time, money, and most critically, your focus. Most early-stage projects don’t fail because they couldn’t scale. They fail because they didn’t solve a real problem, had poor UX, or were never launched in the first place.

AWS Isn’t the Problem. It’s Misuse of AWS.

Let’s be clear. Amazon Web Services (AWS) is an incredible cloud platform. It’s robust, feature-rich, and can scale anything from a scrappy prototype to a planet-wide operation. But here’s the catch.

You don’t need all that power right now.
You don’t need 12 microservices communicating via SNS and SQS queues. You don’t need a separate Lambda for every single route. You don’t need to architect high availability across multiple AZs if no one has even signed up yet.

Here’s what you need: USERS and a working PRODUCT with REAL FEEDBACK.

Your customers don’t care if your backend runs on Kubernetes, Lambda, or a potato. They care about whether your product works, solves their problem, and is easy to use.

Build Fast and Launch Faster

Let’s boil it down.
If you are a solo developer, an indie hacker, or a small team trying to ship a working product, this is all you probably need to start.

A simple €5 to €20 per month virtual private server (VPS) from Hetzner, DigitalOcean, or Linode
Docker Compose to run your app, database, cache, and background workers
A basic Nginx or Caddy server to handle HTTPS and reverse proxy
SSH access to deploy your application manually

That’s it. You can run a real-world SaaS, dashboard, API, or internal tool on a single server for a long time.

Let’s be honest: most MVPs will never outgrow that box. Not for months, maybe not ever. And if they do? That’s a good problem to have. You’ve earned the right to scale.

The Illusion of Infinite Scale

One of the biggest myths in the startup playbook is the obsession with scalability. Everywhere you look, there’s pressure to build for scale from day one. But here’s a better mantra:
Build for survival first. Then scale.

Optimizing for scale without users is like buying more frying pans when you don’t even have ingredients for the meal. Or renting out a stadium before anyone’s bought a ticket to your show.
Spending weeks fine-tuning IAM policies, API permissions, and multi-region deployments before shipping version 0.1 is the ultimate form of procrastination disguised as productivity.

When AWS Makes Sense
Now, let’s be fair. AWS has its place. There are valid reasons to use it, just not for most MVPs.
Here’s when AWS makes sense.

You’re learning AWS for your cloud engineering or DevOps career. You want certification and hands-on practice.
You have strict compliance or residency requirements. Your data must stay in a certain country, or you need specific cloud certifications.
Your product is already scaling fast. You’ve validated the market and have high traffic or specialized infrastructure needs.
You’re deeply invested in the AWS ecosystem. Your team has experience, or you’ve got legacy systems running there.

In these cases, go for it. AWS is amazing when it’s needed. But most projects? They just don’t start there.

And that’s okay. You can always migrate later. When your product has traction and revenue, you’ll know exactly what needs to scale, and why.

How to Ship Without AWS

Still want to launch something real? Want to avoid the rabbit hole of cloud certifications and YAML debugging sessions?

Here’s how to get your project live, today:

Write your application using a solid, battle-tested framework like Django, Rails, Express, or Flask.
Use Docker Compose to define your services, your app, database (PostgreSQL, MySQL), a cache like Redis, and background workers if needed.
Push your code via SSH to your VPS. Run docker compose up -d. Done.
Use Certbot for HTTPS and Nginx or Caddy as a reverse proxy.
Add backups, monitoring, and logs using open-source tools like Prometheus, Grafana, and Sentry.

All this can be done in an afternoon. You don’t need to spend two weeks configuring IAM roles or deciphering CloudFormation templates.

Build to Solve, Not Showcase

If you're building a business, your job is not to showcase how many AWS services you can integrate. Your job is to ship value to users. Quickly. Clearly. Repeatedly.

Let’s be blunt: most MVPs don’t fail due to lack of ECS clusters. They fail because:

Nobody wanted what you built.
The product was too buggy or confusing.
The onboarding was a nightmare.
You burned out from managing unnecessary infrastructure.

Stop trying to impress your tech friends. Impress your users instead.
Solve a real problem. Make it stupid-simple to use. Make it fast. And above all, launch it.

Conclusion
There’s a phrase in the startup world that bears repeating: do things that don’t scale.
Here’s my version: build things that work before worrying about scale.

Start small. Start focused. Deploy your product without turning it into a PhD in cloud computing.
If your product is good, users will come. If it solves a real problem, they’ll tell others. And if you reach the rare and wonderful point of we need to scale, AWS will still be there, ready for you.

But until then?

Close that AWS tab. Fire up your terminal. Launch something simple. Iterate. Grow.
Because big infrastructure won’t save a bad product.

I share amazing content daily, like how I Lost It All – My Tech Story. Also, you can follow me on X to stay updated on what I’m up to in the world of Web3, AI, and what it means to grow as a developer in 2025.