The same problem, in every building we walked into.
Every business we looked at had bought software for each of its problems separately, and then hired people to hold the pieces together. This is the pattern we kept meeting, what we concluded from it, and what we decided to build instead.
Written as chapters, not milestones·Dates published when signed off
How we got to a single ledger.
There is no origin myth here. There is a sequence of conclusions, each of which closed off an easier option than the one we took.
- 01
The pattern
Finance reconciling a spreadsheet against three systems every month. A stock figure nobody trusted. An approval that lived in an inbox. In every business the specifics differed and the shape did not: the record was in pieces, and people were the integration layer.
The problem was not missing features. It was that no two systems agreed on what a thing was.
- 02
The two-systems trap
The obvious answer in this market is to bolt an AI layer onto whatever the business already has. We built enough of those to learn what happens: the model has to be told what a purchase order is, it reads a copy of the data rather than the data, and the copy is wrong by Tuesday.
Intelligence on top of a fractured record inherits the fracture. It cannot be fixed at the top.
- 03
Starting from open
Writing an ERP from scratch would have taken years to reach parity with software that already exists and is already open. So we started from an open-source core with a documented schema, extended it rather than forked it, and put our general changes back upstream.
It also settled the lock-in question permanently: the record is readable without us.
- 04
Agents with a job description
The first agents we built could do almost anything, which meant nobody would let them do anything. So we inverted it. An agent now gets a scope, a ceiling, an escalation path, and no authority to approve its own work — and only then a capability.
Stating the limits first is what made people willing to switch the thing on.
- 05
Delivery as part of the product
A platform that takes eighteen months to configure is not a platform, it is a project. We rebuilt the programme around waves with one genuine process in production early, and published the wave plan on the page rather than holding it for a proposal.
If the plan cannot survive being published, it was never a plan.
Dated milestones.
This table stays empty until each entry has a date somebody will stand behind. It is the one part of a story page that is checkable, so it is the one part we are not going to guess at.
- Incorporated
- To be published
- First production deployment
- To be published
- First multi-tenant group deployment
- To be published
- Agent framework in production
- To be published
- Partner programme opened
- To be published
The rest of the company, in the same words.
Next step
See what the conclusions turned into.
The platform pages are the same argument with the implementation attached.