Why we build for the years after launch
Most software is judged on the day it ships. The systems we are proudest of are judged every day for the decade afterwards.
Insights
Notes from building systems that have to hold up.
Writing from the people who build the work — architecture decisions, domain modelling, interface design and what we have learned shipping into environments where the output gets challenged.
Writing requirements for systems that get argued with
In enforcement, every output is a potential dispute. That changes what a requirement has to say.
Designing for the operator, not the demo
The interface that wins a pitch is rarely the one somebody can work in for eight hours.
Making AI features feel trustworthy in the browser
When a model suggests something, the interface has to make it obvious that a human is still in charge.
Designing for five roles without building five products
Patients, providers, pharmacies, labs and administrators share one system — and almost nothing else.
Ledgers, not columns: why balances should be derived
A number stored in a field is an assertion. A number derived from entries is an argument you can win.
Let's scope your next platform.
Tell us what you are trying to build. We will come back with an approach, a shape for the team and a realistic timeline — not a sales deck.