Modules over repeated forks
Business types select capabilities from a shared foundation organized around configurable boundaries.
Variation lives in modules and settings instead of a fresh codebase for every use.
W.03 / MODULAR BUSINESS SYSTEMS
Scarpar
One foundation. Different businesses. Deliberate boundaries.
SOURCE / GITHUB · 2026-09-15Open source ↗
WHY / DESIGN / BUILD
What shaped the design.
A multi-tenant core with configurable modules and vertical presets, backed by organization-scoped data and operational workflows.
Modules over repeated forks. Business types select capabilities from a shared foundation organized around configurable boundaries.
Carry tenant scope into the data. The architecture documents Postgres row-level policies alongside organization-aware application flows.
Why this
was worth building.
Scarpar explores how much of that foundation can be shared without forcing every business into the same operating model.
Commerce, content and operations repeat many foundations, while each business needs a different set of capabilities.
The underlying
logic.
A multi-tenant core with configurable modules and vertical presets, backed by organization-scoped data and operational workflows.
01Organization
02Enabled modules
03Scoped data
04Storefront + operations
The decisions
inside it.
Carry tenant scope into the data
The architecture documents Postgres row-level policies alongside organization-aware application flows.
Access boundaries belong to the architecture and require their own testing.
What you
can inspect.
An open-source CMS, commerce and business-management platform with modular storefront and administration flows.
Inspect the repository ↗
Some adapters are configuration-gated. Documented access policies are not a claim of an independent security audit or production-scale validation.
Have a related
problem?
Tell me what you want to make possible, where the difficulty is, and what a useful result would look like.