Draft (unpublished). Target: nextagent.ca deep-dive article / members guide candidate. Companion case study: "AI Operations Hub" (/cases/medical-aesthetics-clinic). Privacy: fully anonymized — no client- or patient-identifiable information.
Why modularize
We run a dozen business systems across several servers: a medical-aesthetics operations hub, an internal team OS, an education operations system, a functional-medicine portal, a tutoring platform… A full inventory surfaced one fact: the same capability had been built two or three times. Three time-clock implementations. Three leave-approval flows. Three client profiles. Three booking systems.
Every rewrite repeats the same mistakes, and every new client project starts from zero. That's assets leaking away.
So we built a reuse matrix (capability × project) across all projects and set one simple rule: any capability that appears twice or more gets extracted into a shared module.
Three boundary rules (the constitution)
Extract without a constitution and you get the same mud, sliced:
- A module is a vertical slice of one business capability — a set of tables it owns plus every operation around them. The only test: when one requirement changes, whichever tables change together belong to the same module.
- Modules talk only through public APIs and events. No reaching into another module's tables; tables carry module prefixes; across modules you store only the other side's ID. Dependencies point one way — cycles are banned.
- Platform concerns sink down. Auth, permissions, multi-tenancy, notifications, files, audit and the AI gateway belong to no business module — they form a platform layer reused by all.
Plus three reuse disciplines: shared modules never contain if (client X) (variance lives in
config + extension points); modules are versioned and client projects pin versions; field
differences ride on core columns + JSONB custom fields.
What got extracted: 22 business modules + 8 platform capabilities
Batch by batch, one PR per module, five standard artifacts each (schema / API contract / page contract / config / manifest):
- HR & operations spine (10): employee core domain, time clock, time off, payroll, commission, performance, engagement, staff documents, manager tasks, knowledge base — three forked implementations unified into one.
- Platform (8): multi-tenancy, auth/RBAC, transactional event bus (outbox), module registry with plan gating, hash-chained audit, multi-channel notifications, file storage, AI governance gateway.
- Clinic domain (4): client profiles + leads, booking/scheduling/resources, invoicing/payments/stored-value ledger, treatment records.
- EdTech (3): class operations, teaching (classes/assignments/mastery), question bank with spaced repetition.
- Forms engine (1): dynamic-schema forms and consent, shared by medical and HR flows.
Four pieces of "design IP" the extraction produced
Beyond the module list, the durable value is a handful of production-proven designs:
1. Collections ≠ redemptions. Cash-like payments (cash/card) and entitlement redemptions (packages, memberships, points, gift cards) are booked separately, and across the stored-value purchase→redemption cascade cash is counted exactly once. The system simply does not offer an "add them together" view — so revenue reports reconcile by construction.
2. Cross-module actions become events (the merge contract).
Merging duplicate client records used to be one cascade touching 25 tables in a monolith.
Modularized, the client module migrates only its own tables and broadcasts client.merged;
booking, billing and treatment each subscribe and re-point their own rows. Every module owns
its data; the contract is explicit and testable.
3. Schema-driven clinical records. Treatment types and form fields are pure template configuration (JSONB schema): injectables, energy devices, skin care and IV therapy are just presets — new treatments launch with zero code. Signing locks the record with immutable snapshots for medical compliance.
4. Readiness checks by registration. The booking module never peeks at "is the consent signed?" or "were before-photos taken?" — the forms and treatment modules register their checks with booking. Clean boundaries, independent evolution.
What about external systems
Booking SaaS, EMRs and payment gateways are all demoted to "external mapping + optional sync extension": the core owns its source of truth, third-party IDs live in one mapping table, and sync logic is a pluggable extension. Swap any vendor without touching the trunk.
What this means for the next client
Every module ships with a manifest — a product sheet readable by humans and AI (capabilities / APIs / dependencies / config). Starting a new project now looks like:
- Circle the modules (clinic: clients + booking + invoicing + treatment; education: scheduling + teaching + question bank…)
- Install the platform base (tenancy / auth / event bus)
- Create schemas in dependency order, fill configs, wire events
- Client differences go through config and extension points; failing that, fork a custom edition and register it
From building from scratch to assembling from modules — weeks to start, and every module carries boundaries and accounting rules already proven in production.
NEXT AGENT: we don't sell generic SaaS. We grow your operations into a system of your own.
Learn more: