We build the digital infrastructure public institutions depend on.
We design and build digital public infrastructure, distributed-ledger systems, and other complex software for governments, NGOs, and multilateral institutions.
- Delaware, USA
- Founded 2024
- Governments · NGOs · Multilaterals
Six areas we go deep in.
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.
- Designing registry schemas other agencies can consume without renegotiating the format each time.
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.
- Modelling events as typed, signed records instead of generic blobs.
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.
- Designing recovery paths for a lost device or a forgotten passphrase.
Payments and settlement
Money movement doesn't tolerate a rounding error, a duplicate transfer, or an ambiguous state after a crash.
- Defining custody boundaries so it's always unambiguous who holds funds and when they moved.
Data platforms
Institutions that answer to an oversight body need more than a dashboard.
- Designing ingestion that fails loudly instead of dropping malformed records quietly.
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.
- Designing local-first storage with conflict resolution for devices that sync out of order.
Systems we designed and built.
AXK Network
ChallengeA single shipment of a physical commodity touches a cooperative, a buyer, a bank financing the trade, and often a regulator, and each of them keeps its own record of what happened.
What we builtAfrikabal designed the protocol model and built the platform on top of it: a verified-state system that records the real-world events of a trade, delivery, custody transfer, settlement, as structured, auditable entries that every party can read from the same source.
Read the case study
Rovify
ChallengeA youth athlete's history, which club they played for, which season, what position, what standing, usually exists as a patchwork of team sheets, league spreadsheets, and institutional memory.
What we builtAfrikabal designed and built Rovify as an operating system for the institutions that run youth sports: verified athlete records, league and season management, a tournament engine, and governance for how a transfer between institutions happens.
Read the case study
GetJustly
ChallengeMost people facing a civil legal problem, a wrongful eviction, an unpaid wage claim, a custody dispute, never get in front of a lawyer.
What we builtAfrikabal designed and built GetJustly as a set of connected surfaces: AI legal guidance calibrated to local statute, an encrypted evidence vault with chain of custody, a verified counsel network, and case management tying the three together.
Read the case studyA durable system, then a clean handover.
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.
Architecture
We choose boring, durable technology on purpose.
Build
Delivery is iterative: working software in short cycles, reviewed against the actual scope rather than a fixed contract signed a year earlier.
Handover and knowledge transfer
An institution that depends on us indefinitely hasn't been well served.
Institutions that run public systems.
We build for the kind of institution whose software a citizen depends on. We name the class of institution, never a client.
Governments and ministries
Registries, identity, payment rails, and the data-exchange layers that let separate agencies work from the same facts.
Multilateral and development-finance institutions
Systems with the audit trail and access model an oversight body will actually ask to see, built in from day one.
NGOs and civil-society organizations
Field-ready tools that work offline, on low-end devices, over the channels people already use.
Public agencies and regulators
Shared, tamper-evident records that parties who do not trust each other’s copy can still audit together.
Notes from the systems we build.
Short, technical notes on the engineering decisions behind digital public infrastructure, verifiable credentials, and settlement systems.
Why a registry fails quietly before it fails loudly.
The outage that gets noticed is rarely the first one. A registry usually drifts out of sync with reality long before anyone reports a record that would not verify.
Revocation is the hard part, not the credential format.
A lost phone or an expired licence is the normal case, not the exception. The design question is whether a verifier can trust a credential without being online at the moment of the check.
Reconciliation should be continuous, not a task run at month end.
Money movement does not tolerate an ambiguous state after a crash. We design settlement around explicit custody boundaries, so a discrepancy is visible right away, not caught later in an audit.
Questions a procurement team asks.
Straight answers on ownership, data, formats, and how an engagement runs. If yours is not here, ask us directly.
Who owns the code and the data when you hand over?
You do, outright. At handover the source code, the schemas, the deployment configuration, and the documentation transfer to your institution. We do not keep a licence you have to pay to renew, and we do not hold a copy of your data. The bar we hold ourselves to is whether your own engineers can change the system after we are gone without calling us.
Do you use a distributed ledger by default?
No. A ledger is the right tool only when parties who do not trust each other’s copy of a record have to share one: a cooperative, a bank, and a regulator all needing to agree the same delivery event happened. When one party controls the data and the others only need to read it, a well-designed database with proper access control is faster to build, cheaper to run, and easier for your team to maintain. We tell you which situation you are in before we recommend either.
What does a scope note contain?
What the system is required to do, drawn from your mandate and the policy you have to enforce, not just the initial request. It names the failure modes we will design for, the data the system holds and who can see it, the boundaries with systems you already run, and the constraints that would sink the design if we missed them. It is a working document we build against, not a proposal deck.
What happens at handover?
We document the system as we build it rather than writing it up at the end, train the engineers who will maintain it, and transfer the code your institution owns. Where an institution wants ongoing support or incremental changes as policy shifts, we offer that as a choice you make, not a dependency we engineer in to keep ourselves necessary.
Will we be locked into proprietary formats?
No. Data lives in standard, documented schemas your own engineers can read without us. Exports use standard formats, not a format only our tooling understands. Migrating off our system is a supported path, not an afterthought. If leaving is hard, we built it wrong.
How does an engagement start?
With a fit assessment: what you are trying to enable, where we could plug in, and whether the shapes match. It is a conversation, not a sales script. If it is a fit, discovery and scoping come next, and that produces the scope note before any architecture decision is made.
Tell us what your institution is trying to build.
The first conversation is a fit assessment: what you are trying to enable, where we could plug in, and whether the shapes match. No sales script.