"Monolith first" has been solid advice for close to a decade, and most teams that ignore it aren't ignoring it because they disagree. They're ignoring it because the honest reason to start with microservices was never about the architecture. It was about the resume, the conference talk, or the assumption that whatever Netflix does must be correct for a six-person startup too.
The argument that actually holds up
Microservices solve a real problem: at a certain scale, one team's deploy shouldn't be blocked by another team's tests, one service's traffic spike shouldn't take down an unrelated one, and different parts of a system genuinely need to scale independently. That's a coordination problem, and it's a real one — for organizations with enough people and enough traffic that the coordination cost of a shared codebase has started to exceed the coordination cost of a distributed system.
Most teams reaching for microservices don't have that problem yet. They have three engineers and one product, which means there's no team boundary to decouple, no independent scaling need beyond "the app is slow," and no deploy conflict beyond two people occasionally editing the same file — a problem a monolith with good code review solves for free, without a single network call added to the mix.
What microservices actually cost, that early
The pitch says microservices, the reality bill says distributed systems: network calls where function calls used to be, retries and timeouts to reason about, a message queue or service mesh to operate, and debugging that now spans five services and three logs instead of one stack trace. None of that is optional once you split — it's what "service" means once it's a separate deployable. A three-person team paying that tax before they have the traffic or the org structure to justify it isn't being forward-thinking. They're building a distributed systems problem to solve an organizational problem they don't have yet.
The honest reasons people skip the monolith anyway
Sometimes it really is a scaling need spotted early, correctly, by someone who's done this before — that happens, and it's a legitimate call. More often, the actual reasons are quieter: an engineer wants "microservices" on their résumé because that's what gets interviews at bigger companies. A team read the same blog post everyone else read and assumed the architecture that works at hundred-person-engineering-org scale is the architecture that works at any scale. Or nobody wants to be the one who says "we don't need this yet," because saying so in a room full of people excited about Kubernetes feels like the boring answer.
None of those are bad people making bad-faith decisions. They're normal incentives, quietly overriding an architecture decision that should have been made on its actual merits.
What "monolith first" actually means
It doesn't mean never split. It means build the boundaries inside a single deployable first — clean module separation, clear ownership, interfaces that don't leak into each other — and let the actual pain point tell you where to cut when a team boundary or a scaling need makes the coordination cost of staying together higher than the cost of splitting. A monolith with good internal boundaries splits cleanly later, because the seams are already there. A monolith with no boundaries splits badly no matter when you do it, and a premature microservice architecture splits along guesses instead of along real pain, which usually means splitting it wrong.
The honest version of this advice isn't "monoliths are better." It's: pay the distributed-systems tax when the problem it solves actually exists in your organization, not when it looks good in the architecture diagram before anyone's touched the codebase.