Approx. 8 min read · 1,720 words
The architecture pitch that stopped working
Six years ago, almost every early-stage SaaS team that walked into our Bangalore office wanted microservices on day one. Last quarter, we shipped four SaaS MVPs. Zero of them used microservices. We've quietly reversed our default recommendation, and the reasoning is more practical than ideological. For most early-stage teams, microservices for SaaS MVPs are a tax you pay before you've earned the right to pay it.
Microservices for SaaS MVPs were never wrong in theory. They were oversold in practice. A senior team with platform engineers, real traffic, and a clear bounded-context map can absolutely justify the split. But that is not where most pre-seed and seed-stage teams sit. They are trying to ship five user stories before payroll runs out. They do not have the operational muscle to run a fleet of services, and they pay for that gap in slow releases and 2 a.m. pages.
Honestly, the loudest sign things had shifted came from our own internal data. We started tracking how many engineering days went to "infrastructure plumbing" versus "user-visible features" across our SaaS MVP engagements. In 2022, split-service MVPs spent 38% of total dev hours on plumbing. The modular-monolith MVPs we shipped in 2025 averaged 12%.
What actually changed between 2019 and 2026
The framing in 2019 was: "monoliths don't scale." That was always slightly misleading. Monoliths scale fine to tens of thousands of users on a single Postgres instance. The problem was always organizational, not technical. Once you have eight teams each pushing to a single repo, lock contention on the deploy pipeline becomes the bottleneck.
Most SaaS MVPs in 2026 don't have eight teams. They have three engineers and a half-time founder who still writes code on weekends. The constraint everyone optimized for in the service-first era, team autonomy at scale, simply does not apply.
What did change is the tooling around modular monoliths. Laravel 12, Rails 8, NestJS, and Django all ship with first-class module boundaries now. Patterns like Shopify's component-based monolith and Basecamp's "Majestic Monolith" gave teams a vocabulary for clean service boundaries inside one deployable. Martin Fowler's original microservices essay is also worth re-reading in this light: it never said "always split your services," it said "here are the trade-offs." The trade-offs got worse for small teams, not better.
When the split still makes sense
We are not against splitting services. We run them ourselves on three production accounts where the math works. The pattern we look for is concrete:
- The product has a workload class that is genuinely different from the rest, for example a video-encoding pipeline alongside a transactional billing system
- Two or more engineering pods need independent release cadences
- Specific compliance boundaries demand process-level isolation, as some HIPAA and PCI workloads do
- The team has at least one platform engineer or SRE on payroll, not borrowed
If three of those four boxes are checked, we will happily design a service-oriented architecture. If zero or one is checked, which is the typical SaaS MVP, we push back. Hard.
Modular monolith vs microservices for SaaS MVPs: numbers we actually see
Below is a snapshot from our last six SaaS MVP engagements. The numbers are not theoretical; they are what we observed across actual launches.
| Metric | Microservices MVP (avg) | Modular monolith MVP (avg) |
|---|---|---|
| Time to first paying customer | 14 weeks | 9 weeks |
| Cloud bill, month 1 | $640 | $110 |
| Engineering hours on infra setup | 240 | 60 |
| Mean time to recovery (incident) | 52 minutes | 14 minutes |
| Average PR merge time | 3.1 days | 0.8 days |
None of those gaps close on their own. They compound. A team that spends 240 hours on infra setup before shipping a feature has, by definition, less runway. We have watched founders raise a bridge round to cover the difference. That is a high price to pay for an architecture decision that should have been a non-decision.
Trade-offs the conference talks skip
The split-architecture crowd is honest about the wins. They are less honest about the failure modes that bite SaaS MVPs in particular. Here are the ones we keep seeing in postmortems.
Distributed transactions are real. The moment a user-creation flow has to write to three services, you need outbox patterns, idempotency keys, and a saga. None of that is hard for a senior engineer. All of it is hard for a three-person team trying to ship payment integration this week.
Local development stops being local. A modular monolith runs with one command. A six-service architecture needs Docker Compose, a service mesh stub, and probably Tilt or Skaffold. New hires lose two days to setup. Multiply that by every contractor you onboard.
Observability is not free. You cannot debug a production incident in a distributed system without tracing. That means OpenTelemetry, a backend like Honeycomb or self-hosted Jaeger, and a culture of instrumenting every span. None of that exists on day one of an MVP.
Look, none of these are deal-breakers for a mature team. They become deal-breakers for a team that should be focused on customer interviews, not on writing a Kubernetes Helm chart at midnight. We have covered some of this in our breakdown of SaaS partner red flags: a partner that pitches you Kubernetes for a 50-user MVP is solving for the wrong problem.
How we would build a SaaS MVP in 2026
If a founder walked in tomorrow with a B2B SaaS idea, here is the stack we would recommend without hesitation:
- Single deployable, Laravel 12 or NestJS, with a modular folder structure and explicit module boundaries
- One Postgres instance with schema-per-tenant or row-level security; SQLite is fine if you are truly pre-revenue
- Background jobs in the same codebase, using Laravel Horizon, BullMQ, or Sidekiq, not a separate worker service
- One Redis instance for cache, queue, and session store
- Vercel or Render for the frontend, a single VPS or Fly.io machine for the backend
- One CI pipeline, one deploy command, GitHub Actions calling a deploy script
That stack costs under $50 per month, ships features in days, and supports tens of thousands of users before anything needs to change. When the day comes that one module clearly needs to scale independently, you peel it off. Not before.
This is the same logic we walked through in our SaaS-for-startups playbook. The architecture should match where you are, not where someone hopes you will be in two years.
If you are an SME owner or non-technical founder, the practical question is not "monolith or microservices." It is "how do I make sure my engineering team is not burning runway on plumbing?" Two questions to ask any prospective tech partner: how many services will you deploy in month one, and what does each cost to run? Can you ship a working feature end-to-end in week one, on a staging URL I can see? If the answer to the second is "we need three sprints to set up infrastructure," walk away. Our team handles this conversation regularly inside our SaaS engineering practice; the first deliverable on every engagement is a working slice of the product, not a Helm chart.
For developers reading this: a clean modular monolith is harder to maintain than a clean microservice architecture in some respects. But "clean" is doing a lot of work in that sentence. Most of the SaaS codebases we audit are not clean in either form. The modular monolith degrades more gracefully when discipline slips. The split architecture turns into a distributed mud-ball that costs three times as much to refactor.
Frequently asked questions
Are microservices ever the right choice for a SaaS MVP?
Rarely, but yes. If you have a workload that is genuinely different from the rest of the system, for example real-time video processing alongside a SaaS CRUD app, splitting that one workload into a service is sensible. The mistake is splitting everything by default.
Will we have to rewrite the monolith later?
Probably not, if the modular boundaries are real from day one. Shopify, Basecamp, and GitHub all run massive modular monoliths. The "you'll have to rewrite" claim is often a self-fulfilling prophecy from teams that never enforced module boundaries.
Doesn't a monolith become a scaling bottleneck?
A vertically scaled Postgres instance plus a horizontally scaled application server handles tens of millions of requests per day. The bottleneck almost always shows up in the database layer, not the app layer. Sharding or read replicas solve that without splitting the application into services.
Can we start with a monolith and migrate later?
Yes, that is the whole point. Strangler-fig migrations, where you peel off one bounded context at a time, work well when the monolith is modular. They are nearly impossible when the monolith is a tangle of cross-references. The discipline you invest now pays off if and when you actually need to split.
Should we still hire engineers with distributed-systems experience?
Hire engineers who have shipped products. The architecture experience that matters in 2026 is module boundaries, observability, and database design, not Kubernetes specifically. Our talent staffing team has a hiring playbook around this; the engineers who say "it depends" are the ones you want.
Final take
The service-first era was a useful overcorrection from the 2010-era PHP-spaghetti monolith. It is no longer the right default. For SaaS MVPs in 2026, the modular monolith ships faster, costs less, and stays maintainable longer than the alternative, provided the team takes module boundaries seriously.
If you are partway into a split-service build and the cracks are starting to show, we are happy to take a second look at the architecture without a sales pitch. Book a 30-minute architecture review and bring whatever you have. Sometimes the right answer is to keep going. Sometimes it is to consolidate. Either way, we would rather you make the call with a clear head than discover the problem at the next funding round.
