Skip to content
← All insights
Orchestration

One console, many companies

How a single operations console serves separate companies without ever crossing their data: contracts, isolation, and failing closed.

One console above a fourteen-pin contract connector; below it, three separate sockets for three companies, divided by walls, the third drawn dashed as the next configuration. ONE CONSOLE 14 KEYS COMPANY A COMPANY B NEXT · CONFIG DIGI-DNA · NOTES 2026-10-20 ONE CONSOLE PLATE

We built an operations console for one company and a second company immediately needed the same thing. The tempting move is to fork the code. The right move is to make separation a property of the architecture.

A contract, not a copy

Every company's database implements the same fourteen-key feed. The console reads the contract, never the company's tables directly. A check fails the build if any implementation drifts from the contract, so a change for one company cannot silently break another.

One codebase deploys separately for company A, company B and a third company still in configuration. Each deployment has its own sign-in lock, its own theme variables, its own mail function and its own database, behind walls with no shared state. A single build-time check runs through each company's fourteen-key contract connector. ONE CODEBASE DEPLOYMENT A DB A COMPANY A DEPLOYMENT B DB B COMPANY B DEPLOYMENT C DB C NEXT · CONFIG BUILD-TIME CHECK · 14-KEY CONTRACT WALL · NO SHARED STATE 12 COLOR VARIABLES 1 2 3 4 5 DIGI-DNA · NOTES 2026-10-20 HUB + ENTITIES FIG. 1
Fig. 1Hub and entities. (1) One codebase. (2) A separate deployment per company, each with its own mail function and signature. (3) Every database implements the same fourteen-key contract; one build-time check runs through all of them. (4) No shared runtime state between companies. (5) Sign-in fails closed.Full-size drawing for Fig. 1 (SVG)

Isolation by deployment

One codebase, separate deployments. Each deployment reads only its own company's database and sends only through its own mail function, which owns that company's signature. There is no shared runtime state to leak.

Brand as variables

Twelve color variables and nine panel types. No component names a color. Each deployment looks like its own company because the theme is data, not code.

The operations console deployed for a second company, in that company's own colours and type.
Fig. 2Same console, second deployment: the theme variables carry the company's brand.Screenshot of the running system on synthetic demo data; no client records shown. Client: Charleston Brothers Construction, shown as a separate entity; no endorsement implied.

Fail closed

Sign-in is restricted to the company's own domain, membership is re-checked on every request, and if the allowlist is ever empty the console refuses everyone. The safe failure is a locked door, never an open one.

The result is a product rather than a project: the next operation is a configuration, not a rebuild.

Build the system behind the outcome.

Start a Strategic Build →