Starting with a monolith beats starting with microservices

Hypothesis

For a new product with an unsettled domain, a single deployable with clear internal module boundaries will, over the first one to two years, require less engineering effort per delivered feature and cause fewer production incidents than an initial microservice architecture, because service boundaries drawn before the domain is understood are the wrong ones and are expensive to move.

Prediction

Teams starting with microservices will report more cross-service changes per feature and more incidents attributable to inter-service communication; teams starting with a modular monolith will later extract services along boundaries that have already stabilised, with few cross-cutting changes afterwards.

Proposed test

1. Compare similar products (team size, domain novelty) that chose each approach, tracking features delivered, incidents and cross-boundary changes per feature over 18 months.
2. Within one organisation, record how many initial microservice boundaries were later merged or redrawn.

Status

No result claimed. Fowler's article argues the position from experience reports; counter-examples exist where organisational scale demanded early separation.