I've had this conversation about fifty times in the last year. A founder with a fresh idea, a small team, maybe some seed money, asks me: "Should we go microservices from the start so we don't have to rewrite everything later?"

The short answer is no. The longer answer is the rest of this post.

First, let's kill the confusion

A monolith is one application. All your features — user accounts, payments, search, notifications — live in one codebase, deploy as one unit, talk to one database. You push code, the whole thing ships.

Microservices means you split that application into many small, independent services. Each one does one thing. Each one has its own code, its own database, its own release process. They talk to each other over the network — one service sends a request, another responds.

From the outside, users can't tell the difference. It still feels like one product. The distinction is purely an engineering and operational one.

Why monoliths win for startups

Here's the thing nobody on Twitter wants to admit: monoliths are faster to build, cheaper to run, and easier to fix.

Speed. You have one codebase. One project to open. One thing to run on your laptop. You change something, you test it, you ship it. There's no "well the Orders service needs to talk to the Inventory service which calls the Notification service" chain to untangle. When you're racing to find product-market fit, this matters more than anything. Every hour your engineers spend wiring up inter-service networking and cross-service logging is an hour they're not shipping features to actual users.

Cost. A monolith runs on one server talking to one database. That's maybe $200/month for a small team. Microservices? Expect 3–6x that from day one — you need a traffic router in front of everything, a separate database for each service, tools to manage all those moving pieces, and monitoring dashboards for each one. Microservices are objectively more expensive at every stage. You only recoup that cost if you reach a scale where selectively adding capacity to one part of the system saves you more than the operational overhead costs you.

Debugging. Something breaks in a monolith, you look in one place. Something breaks in microservices, you're stitching together logs from six different services trying to figure out which one dropped the ball. You need specialized monitoring software, dashboards, and cross-service tracing — and someone who knows how to set all of that up. At three engineers and zero paying customers, that person doesn't exist on your team.

Deployment. One application, one automated build-and-release process, one deploy. With microservices, even a modest system might have 10–15 separate release pipelines. Each one needs to be configured, maintained, and monitored. That overhead grows with every new service you add.

The real problems with monoliths (and when they actually bite)

I'm not going to pretend monoliths are perfect forever. They have real issues. But here's the key: those issues show up at scale, not at launch.

The codebase gets big. Once your monolith has 50+ modules and it takes a new developer a month to understand the system, you're feeling the pain. But that's a problem you have when your product is successful. That's a good problem.

Releases slow down. When every small change requires redeploying the whole application and running the full test suite, release cycles drag. But again — this happens when you have a large, mature product with lots of features. Not when you're building v1.

Scaling is blunt. If your search feature is getting hammered during a sale, you can't scale just search. You scale the whole app. This wastes money at high traffic. But "high traffic" means you have customers. You have revenue. You can afford to solve this problem then.

The pattern is clear: monolith problems are success problems. Microservice problems are day-one problems.

When microservices actually make sense

Microservices aren't bad. They're a tool. A very expensive, complex tool that solves specific problems at specific scales. The mistake most teams make is treating microservices as a starting architecture instead of a destination you migrate toward when the pain justifies it.

You should think about microservices when:

Your team is big enough that coordination is the bottleneck. If you have 40 engineers and releases are blocked because Team A's code isn't ready and Team B can't ship independently — that's a real org-level problem that microservices can solve. Each team owns their service, deploys on their own schedule. But notice the threshold: 40 engineers, not 4. Roughly 4 in 10 teams that adopted microservices have consolidated back to simpler architectures because the operational drag outweighed the autonomy gains.

You have clear, genuinely independent domains. If your payment processing has nothing to do with your recommendation engine and they change at completely different rates, separating them can reduce risk. But be honest about whether the boundaries are truly independent. Most "independent" services turn out to need each other's data constantly, and then you're just making what should be internal function calls across the network instead — slower and more fragile for no real benefit.

You have a specific, proven scaling bottleneck. Not "we might need to scale someday" — an actual, measured bottleneck where one part of the system needs 10x the resources of everything else. Then pulling that piece out as its own service makes economic sense. Amazon did this post-2001 when their growth broke their monolith. They now run 700+ microservices handling 2 billion requests per day. But they earned that complexity over years, not on a whiteboard before launch.

You're plugging into an existing high-traffic system. If your new service is going to receive a million requests from day one because it's hooking into an existing platform, plan accordingly. But this is rare for a startup building a new product from scratch.

The move everyone's actually making: modular monoliths

A lot of well-run teams in 2026 aren't choosing between monolith and microservices. They're building modular monoliths — a single application you ship as one unit, but with clear walls between its internal parts.

Think of it this way: your code is organized as if it could be split into separate services, but it all ships as one thing. Each part of the app talks to other parts through defined doorways, not by reaching into each other's guts. No tangled dependencies.

Shopify does this. They handle Black Friday traffic — billions in transactions — on a modular monolith. GitLab does this. Their entire dev platform runs as one application with well-defined internal modules.

The practical upside: if you ever need to pull a piece out into its own service, you can. The boundaries are already there in the code. You don't need a full rewrite. You remove a piece that's already designed to stand alone.

Compare that to a team that split into microservices too early and now has a "distributed monolith" — all the network complexity of separate services, but everything still depends on everything else. That's the worst of both worlds, and it happens all the time. A messy monolith is a big ball of mud. A messy microservice system is that same ball of mud, except now the mud is spread across a dozen servers and every call between them can fail.

If you're building an AI product, this applies double. A single codebase makes it far easier to wire together your data processing, model training, and the app that serves users. You can always split the compute-heavy parts into their own services later, once you know which parts actually need dedicated hardware. Splitting before you've proven the product works is pure waste.

The playbook

Here it is, plain and simple:

Pre-product-market fit: Monolith. No debate. Ship fast, learn fast, spend as little on infrastructure as possible. Your monolith isn't technical debt — it's technical momentum.

Post-PMF, growing team, feeling the pain: Modular monolith. Clean up your boundaries. Make modules independent internally. This buys you time and keeps things simple.

Large org, proven bottlenecks, independent teams: Start extracting microservices selectively. Not all at once. Pull out the pieces that genuinely need independent scaling or independent release cycles. Leave everything else alone.

Amazon started as a monolith. Netflix started as a monolith. Uber started as a single-city monolith in 2011. They all migrated to microservices — after they had millions of users and hundreds of engineers. They didn't start there, and neither should you.

Meanwhile, Basecamp and DoorDash moved back toward monoliths when they realized the microservice boundaries weren't earning their keep.

The bottom line

If you're a startup founder reading this in 2026, here's what I'd tell you over coffee:

Build a monolith. Make it clean. Ship your product. Get customers. When — and only when — the monolith's limitations are actually costing you money or speed, start splitting. You'll know when that time comes because the pain will be obvious and specific, not theoretical.

The worst architectural decision isn't picking the wrong pattern. It's spending six months building infrastructure for a scale you never reach.