Documentation

Each of the 30 modules is its own repository, its own Cloudflare Worker and its own database. There is no shared runtime process and no shared database: HR going down cannot take Payroll with it, and a migration in Finance cannot lock a table Billing is reading.

What they do share is a package — erp-core — carrying the design system, the app shell, the UI kit, authentication, the audit trail, and the comment/document/activity panels every record gets. One change there reaches all thirty apps, which is the point: thirty copies of “post a comment” is thirty places for the tenant scope on the read to be forgotten.

The trade is that the shared package is a real dependency with real blast radius. It is consumed from the workspace with link:../erp-core, so every app builds against the working copy and a break is visible immediately rather than on whoever upgrades next.

easymanagex.com              this directory
<slug>.easymanagex.com       each ERP
<slug>.easymanagex.com/api/health   liveness, including the D1 binding

The suite is bound with Cloudflare Workers routes, not custom domains. A zone accepts only 100 Workers custom domains and appneural.com is already at that limit, so a custom-domain deploy there is refused outright. Routes cap at 1000.

src/
  app/(app)/           screens, one folder per menu item
  app/api/             JSON routes
  actions/             server actions — every write goes through one
  lib/domain/          the rules: state machines, gates, readings
  lib/queries.ts       reads, every one org-scoped in its own where
  lib/schemas/         zod, shape validation only
  lib/guard.ts         which role may do what
  db/schema.ts         Drizzle tables
drizzle/               hand-written SQL migrations, applied by wrangler

The split that matters is domain versus schemas. Zod answers “is this submission well formed”. Whether the move it asks for is legal — can this contract go to signature, may this clause be conceded — is a domain question. Rules stated in both places drift, and it is always the copy in the API route that ends up letting something through.

Comments, documents and the audit trail all address a record by the same (entity, entity_id) pair, so a detail page’s three collaboration tabs are three indexed lookups against one shape, and attaching a thread to a new entity costs a descriptor rather than a table.

1  docs/USER-STORIES.md + the product's .dc.html mockup
2  db/schema.ts        real entities, not one flat table
3  drizzle/000N_*.sql  IF NOT EXISTS throughout
4  lib/domain/         state machines as data, gates that return reasons
5  lib/guard.ts        domain roles onto erp-core's Role
6  lib/queries.ts      org-scoped reads
7  lib/schemas/        zod, shape only
8  actions/            re-check the gate; audit every change
9  app/(app)/          lists, 360 detail pages, the signature screen
10 pnpm typecheck && pnpm build

Each product’s mockup defines one signature workflow screen — the thing that app exists to do. Contract’s is clause negotiation; Recruitment’s is interview evaluation; Support’s is the ticket workspace. Build it for real, using the Workbench shape: a queue of work on one side, the item being worked on filling the rest, each pane scrolling on its own.

pnpm db:remote        apply D1 migrations
pnpm run deploy       build and ship the Worker

CI checks out erp-core alongside the app repo, because the dependency is a link: symlink rather than a published package. Turbopack needs its root expanded to the workspace for the same reason.