How we build · for technical teams
Agents write the code.Gates decide what ships.
Our products are built and operated through AI agents, inside a pipeline that refuses to ship what it cannot verify. This page is the architecture and the method, with the numbers.
One spine, three products.
Only the domain noun changes. Auth, tenancy, tiering, billing, PDF, email and lifecycle stay the same. A feature built once has landed in more than one product.
Agent commercemachines as customers
Autonomous servicesrun until a real decision is needed
Domain skinswhat changes per product
The spineshared across the products
The pipeline every change goes through.
The interesting parts are the things the tooling is not able to do: the builder cannot merge, and the gate has no bypass flag.
- SpecA written design for the change.
- PlanA written plan that breaks the work into tasks.
- BuildBuilt test-first, one feature in build at a time.
- VerifyProved against the real running app, not a green build.
- Security gateApproval binds to one commit. A fix commit voids it.
- Human mergeThe builder stops. A person merges and deploys.
Claims with a figure on them.
Each of these comes from a dated record in our own repos.
4,260
signed billing webhook events in one load test, none dropped
14
red-team suites on one product: billing, payments, trial locks, account access
82 of 89
catalogued capabilities live in production, counted 3 September 2026
21
external platforms integrated, counted 3 September 2026
What we do not claim.
A capability that is built but switched off is not a service. These are the lines we hold in our own copy.
That path drafts for a person on purpose.
We check readiness against a tender. We do not assemble submissions.
Automatic sending is limited to acknowledgements on one product.
Deliberately absent from the tooling, not a setting.