Capability, described honestly.
Six areas we go deep in. We describe what a system does and why a choice was made, not how transformative it is. Anything that touches money or identity gets failure-mode work before it gets polish.
- Public infrastructure
- Verifiable records
- Field systems
Six areas, each described by what it does.
Money and identity get failure-mode work first.
Digital public infrastructure
Registries, identity systems, payment rails, and the data-exchange layers that let separate agencies work from the same facts instead of duplicating records. These are systems a state depends on: when one goes down, a citizen can't renew a document, a hospital can't verify a patient, a treasury can't reconcile a payment. Building them well means treating availability and correctness as policy commitments, not engineering nice-to-haves, and designing the audit trail in from the start rather than adding it before a review.
- Designing registry schemas other agencies can consume without renegotiating the format each time.
- Building identity and payment rails with explicit failure modes, not just a happy path.
- Structuring data exchange so agencies share records without duplicating a source of truth.
- Writing the audit trail into the system from day one, not bolting it on before a review.
Distributed ledger and verifiable records
Some records need to be shared by parties who don't trust each other's copy: a cooperative, a bank, and a regulator all need to see the same delivery event and agree it happened. For that narrow case, schema-typed events, signatures, timestamps, and an audit trail that can't be quietly edited are the right tool. Most of the time it isn't the right tool. If one party already controls the data and everyone else just needs to query it, a well-designed database with proper access control is faster to build, cheaper to run, and easier for an institution's own engineers to maintain. We name which situation we're in before we recommend either.
- Modelling events as typed, signed records instead of generic blobs.
- Deciding, case by case, whether a shared ledger or a conventional database is the honest answer.
- Designing an audit trail a third party can verify without trusting the operator.
- Handling the unglamorous failure cases: a node falls behind, a signature fails to verify, two parties disagree.
Identity and credentials
Verifiable credentials and selective disclosure let a person prove one fact about themselves, such as an age threshold or a licence, without handing over the whole underlying document. The hard engineering isn't the credential format. It's what happens when a phone is lost, a credential needs to be revoked, or the verifier has no network signal at all. Recovery, revocation, and offline verification are where most credential systems quietly fail, and where we spend the design time.
- Designing recovery paths for a lost device or a forgotten passphrase.
- Building revocation that propagates without requiring the verifier to be online at the moment of the check.
- Making verification work offline, with a cryptographic proof that doesn't need to phone home.
- Keeping disclosure minimal: a verifier gets the one fact it needs, not the underlying document.
Payments and settlement
Money movement doesn't tolerate a rounding error, a duplicate transfer, or an ambiguous state after a crash. We design settlement flows around explicit custody boundaries: who holds funds, at which point they move, and what happens if a step fails halfway through. Reconciliation isn't a task run at month end; it's a property the system produces continuously, so a discrepancy is visible in hours, not caught in an annual audit.
- Defining custody boundaries so it's always unambiguous who holds funds and when they moved.
- Designing settlement as a sequence of reversible steps, not one irreversible operation.
- Building continuous reconciliation instead of a manual, periodic check.
- Writing failure-mode tests first: a duplicate request, a partial write, a timeout mid-transfer.
Data platforms
Institutions that answer to an oversight body need more than a dashboard. They need ingestion pipelines that don't silently drop malformed records, a schema that's governed rather than improvised field by field, and analytics that trace back to the source record when someone asks how a figure was derived. We build that governance into the pipeline itself, not as a policy document nobody consults.
- Designing ingestion that fails loudly instead of dropping malformed records quietly.
- Governing schema changes so downstream reports don't break without warning.
- Structuring analytics so any figure can be traced back to its source records.
- Building the access model an oversight body will actually ask to see.
Field systems for low-connectivity environments
A field officer with an intermittent signal, a low-end Android device, and an unreliable power supply is a normal condition to design for, not an edge case. We build offline-first, with local writes that sync and reconcile once a connection returns, and we deliver over channels people already use, such as WhatsApp, SMS, and a lightweight web view, rather than requiring an app and a data plan they don't have.
- Designing local-first storage with conflict resolution for devices that sync out of order.
- Delivering over WhatsApp, SMS, and low-end Android instead of assuming a smartphone with a data plan.
- Handling intermittent power: safe writes, resumable sync, no corrupted state after a mid-write outage.
- Keeping the interface usable on a small screen with a slow connection, not just a fast office one.
Have a system in mind?
Tell us the constraint you are designing around. We will tell you what we would build and what we would not.