Build it well, then hand it over.
An institution that depends on us indefinitely has not been well served. We build with durable technology, ship in short cycles, and hand over a system the institution owns and can run without us.
- Six phases
- No lock-in
- Failure-mode work first
Six phases, one continuous sequence.
Discovery and scoping
Before any architecture decision, we spend time understanding the institution: its mandate, the policy it's required to enforce, and the constraints nobody wrote down that would sink a design if we missed them. We ask what the institution is actually required to do by law or policy, not just what the initial request assumes. This phase produces a scope, not a proposal deck.
Produces · spec
Architecture
We choose boring, durable technology on purpose. A ministry's engineers will run this system for a decade after we're gone; a novel framework or an unproven database is a cost they inherit, not a feature they wanted. We default to components with a long track record, clear documentation, and more than one team who knows how to operate them. Novelty has to earn its place against that bar, and usually it doesn't.
Produces · schema
Build
Delivery is iterative: working software in short cycles, reviewed against the actual scope rather than a fixed contract signed a year earlier. Every changed path ships with tests. Anything that touches money or identity gets failure-mode work before it gets polish: what happens on a duplicate request, a partial write, a dropped connection, a revoked credential. Those are the cases a procurement review asks about.
Produces · tests
Handover and knowledge transfer
An institution that depends on us indefinitely hasn't been well served. We document the system as we build it, train the engineers who will maintain it, and hand over code the institution owns outright. The measure of a good handover is whether their own team can change the system without calling us first.
Produces · runbook
Open standards and no lock-in
Data lives in standard, documented schemas, not a proprietary format only we can read. Exports work. Migrating off our system is a supported path, not an afterthought we hope nobody asks about. If leaving is hard, we built it wrong.
Produces · exports
Stewardship
Some institutions want an ongoing relationship after handover: support, maintenance, incremental changes as policy shifts. We offer that where it's wanted. It's a choice the institution makes, not a dependency we engineer into the system to make ourselves necessary.
Produces · trainingConstraints we hold ourselves to.
A public buyer can hold us to these. They are enforced the same way a spec is: in what we build, not just in what we say.
No vendor lock-in. Data stays in schemas your own engineers can read without us.
No proprietary data formats. Exports are standard formats, not a format only our tooling understands.
No ledger where a database is the right answer, even when a ledger would be the bigger invoice.
No dependency on us to keep the system running. Your engineers can operate it without us on the phone.
Ready to scope something?
We'll start with a scope note, not a quote.