Holism describes a shared foundation as the engineering that several business applications can rely on without becoming the same product. A salon, a course provider, and a shop have different work to do, yet they all need identities, settings, localization, reliable APIs, and deployable processes. Building those foundations once can reduce cost for SMB customers when the boundaries remain clear and the shared work is genuinely reusable.
Start with a concrete product need
A reusable module should begin with a capability that one product needs and another could use without inheriting irrelevant business rules. Accounts, access control, and translation are clear examples; a salon's appointment policy is more specific. Identify the stable contract before extracting code. A shared foundation is valuable when a product can use it through a public interface and still control its own workflow. Mere code duplication does not prove a module belongs in the core.
Organize the layers by responsibility
Development, API, panel, and site cores carry broad behavior. Parts add capabilities such as blog, courses, products, and orders. A runnable product composes the relevant parts and adds its niche behavior. These layers are repositories assembled in a container, not independent applications pretending to share a platform. A part should expose a coherent capability, and its leaf code should stay simple because conventions and shared mechanisms live closer to the core.
Keep variation explicit
Two customers may need different languages, visible item counts, layouts, or workflow options. Tenant settings and supported variants should express these differences when they fit the same domain model. A shared module that requires edits for every customer is not truly reusable. Conversely, turning every line into a configuration option makes the system hard to understand. Choose settings for real variation, validate their values, and give each one a clear scope and default.
Preserve part boundaries
A part should consume another part's public contract rather than import its private business files or storage schema. This matters even when everything runs in one container today. Products may assemble different parts or place data in separate databases later. Cross-part data needed for a response should be supplied through the supported API or embedded where the architecture calls for it. Clear boundaries allow a fix to one part without making every product depend on its internals.
Share operational work too
A foundation includes deployment conventions, localization coverage, error handling, caching, and observability. Reusing a form component while every product invents its own release procedure leaves major costs untouched. Common commands and pipelines should make routine work repeatable, while individual products supply their configuration. The platform still needs product-specific testing; shared code can fail under a combination of parts or locales that another product does not use.
Judge success by outcomes
A shared foundation should shorten delivery of a real customer feature, reduce repeated defects, and make maintenance easier. Track whether teams can add a part without copying boilerplate, whether tenant variation stays understandable, and whether incidents can be isolated. If a core abstraction grows too complex, revisit its boundary. Holism's aim is a practical family of products that can evolve together without forcing every customer into the same experience.
Grow from evidence
The first version of a foundation need not predict every future industry. Add capabilities when a product need demonstrates their value, then generalize the stable behavior. Document public contracts and migration expectations. This measured approach fits limited budgets better than building a large theoretical platform before applications use it. Reuse is earned by making ordinary product changes cheaper and safer over time. Each extracted rule should have a real consumer and a named owner.