Why Your MVP Doesn't Need Microservices

You’ve got an idea. You’ve validated it with potential customers. You’re ready to build.

And then someone tells you that you need microservices. A message queue. Kubernetes. Three different databases. A separate service for authentication.

No. You don’t.

The monolith is your friend

Every successful product you admire started as a monolith. Shopify runs on Rails. GitHub ran on Rails for years. Discord’s core is a monolith. Basecamp, WhatsApp, Instagram - all started simple.

A well-structured monolith will handle more traffic than you’ll see in your first two years. Probably your first five.

What you actually need for an MVP

1. One server. A single $20/month VPS can handle thousands of concurrent users.
2. One database. PostgreSQL does 95% of what you need: relational data, full-text search, JSON, geospatial queries.
3. One codebase. Ship features in hours, not days. Deploy in seconds, not minutes.
4. One developer. Me, or someone like me. Not a team of specialists.

When to add complexity

Add complexity when you have a specific, measured problem that simple solutions can’t solve. Not before.

• Splitting into services because your monolith is slow? First check if you’ve added database indexes.
• Adding a cache layer? First check if your queries are optimized.
• Building a separate API? First check if your framework already handles it (spoiler: it does).

The real cost of premature architecture

Every additional service is:

• Another thing to deploy
• Another thing to monitor
• Another thing that can fail
• Another thing to debug at 3am

When you’re pre-product-market-fit, speed is everything. The fastest architecture is the simplest one.

Ready to build simple?

I help founders build MVPs that ship fast and scale when needed. No unnecessary complexity, no architecture astronautics. Just working software that solves real problems.

Let’s talk about your project →