When you map out an ambitious product ecosystem, the catalog grows fast - ours runs to roughly 1,500 distinct items. The naive translation of that number is terrifying: 1,500 repositories, 1,500 pipelines, 1,500 things to deploy, secure, and monitor. We made an explicit decision early that the catalog is a map of capabilities, not a count of services. The two are not the same thing, and conflating them is how organizations drown in operational overhead.
The catalog is capabilities, not deployables
A catalog item is a capability a customer might use - a feature, a building block, a connector. A deployable service is an operational unit you build, ship, and run independently. Most capabilities do not deserve their own service. They are modules that live inside a bounded-context service alongside related capabilities, sharing a deployment, a database, and a team. The result is a few dozen well-bounded services, not fifteen hundred.
The microservice justification rule
To keep that honest, a capability has to earn the right to be its own service. We make it justify the split against a checklist - and if it cannot, it stays a module:
- Does it have a genuinely independent scaling profile?
- Does it need an independent deployment cadence from its neighbors?
- Is it owned by a different team with a different release rhythm?
- Does it have a distinct availability or compliance boundary?
- Would splitting it actually reduce coupling, or just move the coupling over a network call?
If the honest answers are no, a new service adds distributed-systems cost - network failure modes, data consistency across boundaries, deployment coordination - while delivering none of the benefit. The default is module-in-service; a separate service is the exception you argue for.
Note: Every microservice you create is a distributed-systems problem you opt into. The question is never "can we split this?" but "does splitting this pay for the complexity it adds?"
Why platform first
The sequencing follows from the same logic. A huge catalog tempts you to start everywhere at once. Instead we build the core platform first - identity, configuration, audit, billing, communications, documents - because nearly every other product depends on those. Get them right and shared, and every subsequent product starts further ahead. Start the verticals first and you end up reinventing identity and billing inside each one, which is the fragmentation we are trying to avoid wearing a different hat.
Verticals compose, they do not duplicate
With a solid platform in place, an industry-specific product becomes a thin domain layer composed on top of shared building blocks, not a from-scratch rebuild. The vertical brings what is genuinely unique to its domain and borrows everything else. That is only possible because the platform came first and the service count stayed small enough to reason about.
Wrapping up
A big catalog is a sign of ambition, not a mandate for a service explosion. Treat catalog items as capabilities, make each one justify any split with a real checklist, and sequence the shared platform ahead of the verticals that depend on it. The payoff is an ecosystem that can grow to fifteen hundred capabilities while staying operable, because the number of things you actually deploy and run stays deliberately small.
Planning an ambitious platform and worried about sprawl? Let's architect it together.
