The Actual Trade-off
A monolith deploys as one unit and is simpler to develop, test and reason about — at the cost of everything being coupled together as the system grows. Microservices split the system into independently deployable pieces — which solves the coupling problem, at the cost of real operational complexity: network calls where there used to be function calls, distributed debugging, and infrastructure overhead per service.
Where Teams Get This Wrong
Adopting microservices before there's an actual organizational or scaling reason for it — usually before a team is even large enough to need independent deployment cycles per service. That overhead is a tax paid from day one for a scaling problem that may never arrive.
A More Useful Framing
Start with a well-structured, modular monolith — clear internal boundaries, even if it deploys as one unit — and split out a genuine microservice only when a specific part of the system has a real independent scaling, deployment-cadence, or team-ownership reason to exist on its own. That's the same judgment applied to SaaS platform builds here: infrastructure decisions follow actual constraints, not architectural fashion.