DEV Community

Cover image for Peanuts engineering: A practical guide to build fast and scale effectively. Part 0: The philosophy
michael
michael

Posted on

Peanuts engineering: A practical guide to build fast and scale effectively. Part 0: The philosophy

Part 0: The Philosophy

I've killed more side projects with AWS bills than I have from lack of users.

That's a depressing sentence to write, but it's true. I'd get excited about an idea, spin up the "proper" infrastructure - RDS, Lambda, S3, Redis, the works - and then watch the monthly bill creep up while the user count stayed at zero. Eventually I'd just shut it down because keeping a dead project alive was costing me $200/month.

The worst part? None of those projects needed any of that infrastructure. A $5 VPS would have handled everything. I was optimizing for problems I didn't have.

We've Been Sold a Lie

Look, I get it. Cloud providers are convenient. Kubernetes is impressive. Serverless is genuinely cool technology. But somewhere along the way, we started treating these things as the default instead of tools you graduate into when you actually need them.

I've seen developers reach for AWS before they've written a single line of code. I've watched people set up CI/CD pipelines that cost more to run than their server costs. I've debugged "microservices" that have exactly one user - the developer.

Most applications will never need this stuff.

A properly configured VPS can handle thousands of requests per second. You know what's harder than scaling to thousands of requests per second? Getting your first hundred users. But we spend all our time solving the scaling problem and zero time actually building something people want to use.

What I'm Actually Teaching Here

This series is about building things the way you probably should: start simple, stay simple, and only add complexity when you have actual evidence you need it.

Here's the progression I wish someone had taught me:

Phase 0→1: The Weekend Proof of Concept ($0/month)

  • Get it working locally with Docker
  • Set up your environments properly from the start (local/dev/prod)
  • Build something you can demo by Sunday night

Phase 1→2: The Dev Server ($0/month)

  • Expose it to the internet so others can use it
  • Write actual deployment scripts
  • Set up HTTPS because it's not the 90s anymore

Phase 2→3: First Deploy ($5/month)

  • Move to a real VPS
  • Put Nginx in front of it
  • Deploy without downtime
  • Add basic monitoring so you know when things break

Phase 3+: When You Actually Need It ($$$ varies)

  • Horizontal scaling when one server isn't enough (you'll know)
  • Load balancing when you have actual load (you'll know)
  • Cloud providers when the math makes sense (you'll know)
  • Notice how cloud providers show up in Phase 3+? That's intentional.

You might never need Phase 3. Most projects don't.

The Plan

I'm building a language learning app with spaced repetition (think Anki) using Spring Boot. We'll take it from local development all the way through to production deployment and scaling.

Along the way, we'll cover:

  • Auth that doesn't suck
  • Database migrations that won't bite you in production
  • When to split a monolith (spoiler: probably later than you think)
  • Deployment that you can actually understand
  • Monitoring that tells you useful things
  • Performance optimization when it matters (also: when it doesn't)

Who This Is For

If you've ever:

  • Abandoned a side project because of infrastructure costs
  • Wondered why your "hello world" costs $50/month
  • Wanted to understand what you're actually paying cloud providers for
  • Needed to ship something this weekend, not next quarter

Then this series is for you.

If you're running a funded startup with actual traffic and actual scaling problems, you should probably stop reading and go hire a platform engineer.

What's Next

Part 1 starts with getting a working application running locally. No cloud accounts required. No credit card needed. Just Docker, some code, and a weekend.

We'll build something real, deploy it for peanuts, and actually understand what we're doing.

All code will be open source. Follow along, steal the code, make it better.

Questions? Comments? Want to teach me something? Drop a comment below!

Top comments (0)