Building one SaaS product creates pressure to move quickly. Building several creates a second pressure: everything starts to look reusable. Authentication, billing, email, analytics, design systems, deployment, and internal tooling appear in every roadmap.
At Continium, I think about this as a boundary problem. Share too little and every product repeats infrastructure. Share too much and a change for one product can destabilize all of them.
Share capabilities, not assumptions
Good shared components have stable responsibilities. Identity, audit logging, deployment conventions, and basic observability can often be standardized. Product-specific data models and workflows should stay independent until there is clear evidence that they are truly the same.
I avoid building an internal platform just because two codebases contain similar files. Duplication is sometimes cheaper than the wrong abstraction. The right time to extract a shared service is when the behavior, ownership, and failure expectations are understood.
Keep products deployable
Each product should be able to ship without coordinating every other product. That pushes shared code toward versioned packages and narrow APIs rather than direct access to one central database.
Operational visibility should still feel consistent. Common logs, error reporting, health checks, and deployment metadata make it easier to understand the portfolio without forcing the products into one runtime.
Build for the current team
Architecture must match the people operating it. A technically elegant network of services can become a burden if every release requires complex coordination. For a small team, clear modules, automated deployments, and documented ownership usually matter more than maximum theoretical scale.
The goal is not to make every product identical. It is to create enough shared foundation that teams spend their time on the product's unique problem while preserving boundaries that keep failures understandable.