Designed Before a Line of Code (Part 3 of 4)
Seventeen operations features were fully designed and approved before any of them was built. On sovereign infrastructure, that order is the governance.
Trust, Metered — Part 3 of 4. (Start at Part 1.)
Designed before a line of code
In July 2026 we designed seventeen operations features — across financials, fleet and movement, operations, people, and cross-cutting concerns — and got every one of them approved before building any of them. No code. Just designs, decisions, and a register that says, feature by feature, what it is and why it's in scope.
That order is deliberate, and on infrastructure like this it is a form of governance.
The temptation, especially with fast tools, is to build first and rationalise later — ship the feature, then write the doc that explains the feature you already shipped. It feels productive. It also means the hardest questions — how does this touch money, who's allowed to do it, what does it break, is it even necessary — get answered under the pressure of code already written, when the honest answer is expensive to act on.
Designing first inverts that. Every feature reaches a tenant the same way: additively, through configuration, backward-compatible with what's already deployed — a rule we decided before the first migration, not after the first outage. A feature that can't be described cleanly and defended before it exists usually shouldn't exist yet.
It's the same instinct as maker-checker, pointed at the roadmap instead of a transaction: put the review before the irreversible step, not after. A held disbursement waits for a second person; a proposed feature waits for a design that survives scrutiny.
Honest note: this is slower at the start and it takes real discipline to hold, especially when the tooling makes building feel free. But "designed and approved before built" is the difference between a platform that grows on purpose and one that accretes features nobody quite decided on — and on money infrastructure, the second kind is how you end up somewhere you can't explain.
Design before code, approval before execution, a stop button when it all goes wrong. One thread ties them together — and it's the one nobody can quietly cut.