A white-label operating system that turns a service business into a product.
You productise the whole path, not just the software. AgencyOS gives an operator a branded business from lead to contract to payout, runs operator, admin and client portals off one API across 78 data models, and provisions each operator's marketing site from an embedded generator.
Because operators, the platform admin and end clients are looking at the same objects from different angles. A lead, a contract and a payout do not change shape depending on who is reading them; only the permissions do.
Splitting the backend per audience would mean three copies of the same domain model drifting apart. One API with role-scoped access keeps a single source of truth, and the domain is large enough, 78 data models, that duplicating it would have been a serious liability.
It solves a boring problem that ruins platforms quietly. When you write to the database and then publish an event, those two steps can disagree: the write lands and the event never fires, or the event fires and the write rolls back.
The outbox writes the event into the same database transaction as the change itself, then a separate process publishes it. Either both happen or neither does. On a platform that moves money from lead to payout, a silently dropped event is a missing invoice.
Queues absorb the work that must not block a request: provisioning, generation, anything slow or failure-prone. Retries become ordinary rather than exceptional.
Realtime gateways handle the other direction, pushing live updates so operators and clients see the same state without refreshing. Collaboration on a shared record needs both halves.
An embedded generator provisions it as part of onboarding. The operator is not handed a template to configure, they get a branded site as a product of signing up.
That is what separates a business-in-a-box from a SaaS subscription. The operator's customers should never encounter the platform underneath.
Centrally. The platform owner runs every operator from one admin surface and takes a cut of what flows through, so the model scales with operator success instead of with seat count.
That shape puts real weight on the payout path being correct, which is why the reliability patterns above are not decoration.
A production multi-tenant platform spanning 78 data models and three apps, with real distributed-systems patterns under the hood.
| Model | White-label, operator runs a branded business |
|---|---|
| Apps | Operator, admin and client portals |
| Backend | One API, 78 data models |
| Reliability | Transactional outbox for event consistency |
| Async work | Queue-backed workflows with retries |
| Live updates | Realtime gateways |
| Operator site | Embedded marketing-site generator |
| Coverage | Lead to contract to payout |
A way to keep a database write and the event announcing it in step. The event is written into the same transaction as the change, and a separate publisher sends it afterwards. Without it, a crash between the write and the publish leaves the system with a change nobody was told about.
Usually yes, when they operate on the same domain objects. AgencyOS serves operator, admin and client portals from one API because they all read the same leads, contracts and payouts. Separate backends would mean maintaining three copies of a 78-model domain.
The operator's customers see the operator's brand, not the platform's. In AgencyOS that extends past the app to a generated marketing site, so an operator signs up and comes away with a business that looks like theirs rather than a reseller account.
Because provisioning, generation and payout steps are slow and can fail. Doing them inside a request makes the user wait and turns a transient failure into a visible error. A queue makes retrying normal and keeps the request fast.
Proof of which crypto callers actually make money — and a place to backtest it.