Unpopular opinion: Your MVP doesn’t need microservices.

In my experience as a tech lead building early-stage SaaS products:

We once tried to go all-in on microservices architecture right from the MVP stage. It sounded right: scalable, modular, flexible. But the reality? It was a pain to manage. Too many repos, too many CI/CD pipelines, duplicated auth, monitoring everywhere, and so much effort just to keep services talking to each other.

Meanwhile, the product requirements kept evolving fast. Features got cut, priorities shifted, and we spent more time maintaining the infrastructure than shipping value.

We eventually consolidated into a single backend service using NestJS. It simplified everything: faster iterations, less deployment overhead, and clearer ownership. In another project, we even used Next.js Server Components directly connecting to Supabase, no custom backend needed at all.

🧠 My lesson? MVPs are not about elegance or long-term scale. They’re about learning quickly, validating ideas, and responding to real user feedback.

🛠️ Unless you’re solving a domain-specific architecture problem on day one, start with:

A monolithic backend (NestJS or FastAPI work great)

Or skip the backend and use Server Components + BaaS (like Supabase)

Optimize for developer experience and product velocity

⚡ Fast feedback loops > “perfect” architecture. You can refactor when the time is right, after product-market fit.

Agree? Disagree? I’d love to hear your take in the comments.

Or message me if you’re building an MVP and unsure about the architecture path, happy to share what worked for me.