Teams usually ask me about this after the pain has already started.
A counter to the microservices reflex small SaaS teams have: module boundaries via domain folders, contracts, and events inside one deployable, plus the three concrete signals that justify extracting a service later. Aimed at the CTO who was told the monolith won't scale.
The short version
The honest answer depends on your context — team size, existing stack, and how much of the problem is really technology versus process. But the pattern I see repeatedly: start from the business constraint, not the tool. If you are researching modular monolith laravel, the framing below is the one I use with my own clients.
How I approach it
- Name the constraint first — cost, speed, compliance, or maintainability — and let it drive the architecture.
- Prefer boring, proven building blocks; spend novelty budget only where it buys a real advantage.
- Measure before and after. If a change cannot show up in a number, it is a matter of taste, not engineering.
You can see how this philosophy plays out across my technology stack.
A full write-up of this topic is in progress — this is the working summary. Facing this decision right now? Let's talk.