# Monolith vs microservices for startups in 2026

*By Roberto Lazar, founder of Dock30 · Published 2026-08-05 · Updated 2026-08-05 · 8 min read*

When a monolith beats microservices for a startup, where the modular monolith fits, and the operational cost teams underestimate before they scale.

For almost every startup in 2026, the right first build is a monolith, ideally a modular one: a single deployable application with clean boundaries inside it. Microservices solve problems of team size and scale that a young company does not have yet, and they charge for that solution from the first commit. Build one codebase you can ship in one step, keep strict internal module lines, and carve out a separate service only when a specific, measured problem makes you.

That advice is not new, and the industry has spent the last few years walking back the microservices-by-default reflex it picked up around 2018. We build custom software from Romania, and on client work since 2021 the pattern has held: the teams who reach for microservices early spend their first months on infrastructure instead of product, and the teams who start with a well-organized monolith ship, learn, and only then split what genuinely needs splitting.

## Why monolith-first is almost always right for a startup

Martin Fowler made the cleanest version of this argument back in 2015, and it has aged well. In [MonolithFirst](https://martinfowler.com/bliki/MonolithFirst.html) he points out that nearly every successful microservice system he had seen started life as a monolith that grew too big and got broken up, while the systems built as microservices from scratch tended to end in trouble. His reasoning is what he calls the microservice premium: the cost of operating a fleet of services slows a team down, so the pattern only pays off once a system is complex enough to need it.

A startup is the opposite of that situation. You do not yet know where the real boundaries in your product are, because you do not yet know which features will survive contact with users. Draw service boundaries on day one and you are guessing, and a wrong boundary in a monolith is a refactor while a wrong boundary between services is a migration across a network. One deployable app also means one place to run, one place to debug, and one transaction when two things have to happen together or not at all. When you are three to eight engineers, that simplicity is most of your speed.

David Heinemeier Hansson, who built Basecamp and Ruby on Rails, has been making the same case for a decade under the banner of [the majestic monolith](https://signalvnoise.com/the-majestic-monolith/): a small team has no business carrying the coordination weight of a distributed system, and a single well-kept application will take that team much further than most people expect. He is not describing a toy. He is describing the architecture behind products that run real revenue.

## The modular monolith middle ground

The worry people have about monoliths is the big ball of mud: one codebase where everything imports everything and no change is safe. That is a discipline problem, not an architecture law, and the answer to it is the modular monolith.

A modular monolith is still one deployable application, but internally it is split into modules with hard boundaries. Each module exposes an explicit interface, one module never reaches into another module's database tables, and calls between modules go through those interfaces rather than around them. You get the conceptual separation microservices promise, enforced in the codebase, without a single network hop.

Shopify is the reference example at scale. Their core is a Ruby on Rails application of well over two million lines, and rather than shatter it into services they [reorganized it into a modular monolith](https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity), using a boundary-enforcement tool to make each component declare its dependencies and public interface. That codebase processes an enormous volume of commerce and stays a monolith on purpose. This is not a fringe position anymore either. InfoQ's [2025 architecture trends report](https://www.infoq.com/articles/architecture-trends-2025/) places the modular monolith in the early-majority band, meaning it has moved from contrarian take to mainstream default.

The other quiet benefit is optionality. When a module in a clean monolith eventually does need to become its own service, the seam is already cut. You are extracting along a line you have been maintaining for months, which is a normal week of work rather than an archaeology project.

## When microservices genuinely pay off

Microservices are a real tool with real uses. They just answer questions about organization and scale, not about code quality, and there are three situations where they earn their cost.

The first is organizational scale. Once you have many teams working on one product, a single deployable becomes a coordination bottleneck: every release is a negotiation, and one team's bug blocks everyone else's ship. Splitting the system so each team owns and deploys its own services removes that contention. This is Conway's law working in your favor, and it starts to matter somewhere north of a few dozen engineers, not at eight.

The second is independent deployment. If one part of the system needs to ship several times a day while another part changes once a month, forcing them into the same release train slows the fast part down to the speed of the slow part. Separating them lets each move at its own cadence.

The third is isolated load. When one component has a resource or hardware profile wildly different from the rest, sharing infrastructure wastes money. A video-processing pipeline that needs GPU instances should not sit in the same deployable as the REST API serving account settings, because you would be paying to scale both when only one is under pressure. Pull that component out and scale it on its own.

If your situation matches one of those, extract the specific piece that needs it. That is very different from splitting the whole system into a dozen services because a conference talk said to.

| Signal | What to build |
|---|---|
| One team, roughly under ten engineers, product still finding its shape | A monolith, kept modular from the start |
| Growing codebase, a few clear domains, still one team | A modular monolith with enforced boundaries |
| Several teams blocking each other on releases | Extract the contended services along team lines |
| One component with a very different load or hardware profile | Split that component out, keep the rest together |

## The operational cost most teams underestimate

The reason microservices-by-default fell out of favor is that the bill came due. The moment a function call becomes a network call, you inherit a distributed system, and distributed systems fail in ways a monolith cannot. Requests time out, so you need retries. Retries can double-charge someone, so you need idempotency. A single user action now touches five services, so you need distributed tracing just to answer "why was this slow." Two services can no longer share a database transaction, so you write reconciliation logic to keep data consistent. A new developer has to spin up the whole constellation to run the app locally.

None of that ships a feature. It is the tax you pay for the split, and it lands whether or not you are getting the benefit. Independent analyses in 2025 put the resource overhead of microservices at roughly a quarter more infrastructure than an equivalent monolith, before you count the extra platform engineers a fleet of services needs on the payroll.

The most quoted cautionary tale is Amazon's own. The Prime Video team rebuilt one of its video-quality monitoring pipelines, moved it from a spread of distributed serverless components back into a single application, and [cut the running cost of that pipeline by about 90 percent](https://www.thestack.technology/amazon-prime-video-microservices-monolith/). The honest reading of that story is not "Amazon abandoned microservices." It is narrower and more useful: for that particular workload, the coordination and data-shuffling overhead of the distributed version cost far more than the monolith it replaced. Even the company that helped popularize the pattern found a case where the simpler shape won by an order of magnitude.

There is a second trap worth naming. A lot of teams that call themselves microservices deploy all their services together anyway, in one lockstep release. That arrangement carries every cost of a distributed system and delivers none of the independent-deployment benefit that was the whole point. It is the worst of both, and it is more common than anyone admits.

## What we build for clients

We ship monolith-first and modular monoliths for almost every client, and we will tell you when microservices are complexity you do not need to buy. Our default backbone is a single deployable [Next.js, NestJS, and Postgres stack](/blog/fullstack-nextjs-nestjs-postgres-railway), one API you can run and reason about in one place, organized into modules so it stays navigable as it grows. That covers the large majority of what founders actually need, from internal tools to customer-facing products, and it leaves the door open to extract a service later if the business earns one.

Building from Romania keeps that pragmatism affordable. Fixed-scope projects start at **EUR 350**, with the exact price and delivery date agreed in writing before any work begins, so the architecture conversation is about what your product needs rather than what runs up the most hours. The [project pricing](/pricing/project) is public, and if you want the wider market context we broke down [what custom software costs in 2026](/blog/custom-software-cost-2026) separately. When software needs to keep evolving after launch, monthly partnerships start at EUR 1,000, and every launch includes 30 days of free support. You can see the shape of these builds on our [custom development](/services/custom-development) page.

If someone is quoting you a microservices architecture for a product that has not launched, ask them which of the three real triggers you are hitting. If they cannot name one, you are being sold complexity, and it will show up in both the timeline and the invoice.

If you are weighing this decision for your own product, the cheapest next step is a short conversation. Book a [free 15-minute call](https://calendly.com/dock30/15min) or reach us through the [contact page](/contact), and we will tell you honestly whether your build wants a monolith, a modular monolith, or the one service worth splitting out. More often than not, it is the monolith, and we will say so before you spend a euro finding out the hard way.

## Frequently asked questions

**Should a startup use microservices or a monolith?**

For almost every startup, a monolith is the right first build. Microservices solve problems of team scale and independent deployment that a small company does not have yet, and they add real operational cost from day one. Start with one deployable application and split out services only when a concrete problem forces you to.

**What is a modular monolith?**

A modular monolith is a single deployable application with strict internal boundaries between its parts. Each module has an explicit interface, modules do not reach into each other's database tables, and the whole thing still ships as one unit. You get most of the clarity of separate services without running a distributed system.

**When do microservices actually make sense?**

Three situations justify the cost: you have several teams that block each other on releases, you need one part of the system to deploy on its own schedule, or one component has a load or hardware profile so different that sharing infrastructure is wasteful. If none of those apply, the split adds complexity without a matching benefit.

**Can you split a monolith into microservices later?**

Yes, and that is the usual path for successful products. A monolith with clean module boundaries is far easier to carve up than a tangled one, because the seams are already there. Most well-known microservice systems started as a monolith that grew and got broken apart, not as microservices from scratch.

**Is a monolith bad for scaling?**

No. A single application scales a long way by running more copies behind a load balancer, and most startups never outgrow that. Scaling limits usually come from the database or one hot code path, both of which you can address without splitting the whole system into services.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact