Paper, filled in by the wrong hands.
The DRC produces over 70% of the world's cobalt. Up to a third of it is dug by hand, in a sector that sustains an estimated 10 million people. Almost none of them can open a bank account: surveys put banking access among artisanal miners at 1 to 3%. The gap is filled by informal lenders on predatory terms, which is part of why the sector stays dangerous and informal.
The blockage isn't the miner. It's the paperwork. Banks need to verify identity, source of funds and due diligence before they can say yes, and that record doesn't exist where there is no filing system, no shared registry, no compliance function. The process ran on paper forms, usually filled in by a bank agent on the operator's behalf. The person answering wasn't the person who knew. The bank inherited data it couldn't defend, and the easiest decision was always no.
So the operator is judged by what is missing, and the informality that makes compliance impossible becomes the evidence against them.
Change who holds the pen.
KOTA moves the starting point: the operator registers themselves, answers the basic questions, and submits digitally. The bank receives a structured application instead of a stack of handwritten cards — and the operator gets a score that shows the path forward, not just the verdict.
One engine serves two institutions — a commercial bank and a government-mandated commodity aggregator — wearing different vocabulary. Those product decisions belong to the team; my work happened one level down: giving every one of them a form people can use.
The People
Three actors, one compliance pipeline.
KOTA is not a single-user product. Three distinct roles touch the same data, at different moments, with different needs — and the platform has to serve all of them without asking any one to work like another.
Gains agency over their own approval.
Cooperatives and small producers in extractive industries — the people KOTA is built for — go through due diligence without a compliance team or a filing system. KOTA gives them the tools to register themselves, track their application, and understand exactly what's holding them back. The score makes the process legible: not just a verdict, but a map.
Replaces a manual pipeline with a structured one.
Banks receive applications they can actually evaluate — organized forms, uploaded documents, stage-gated workflows — instead of handwritten cards filled by an agent on the client's behalf. Registration and evaluation are separated because they belong to different roles inside the bank: what KOTA makes explicit, the bank has always needed.
Onboards its supply chain into a compliance framework.
An aggregator that buys from cooperatives and sells to international markets has direct exposure to supply chain regulation — EU conflict minerals rules, OECD guidance, ESG requirements from buyers. KOTA lets them run that process using the same platform as the bank, adapted through configuration rather than a separate product.
Financial inclusion meets regulatory pressure.
The informal economy in sub-Saharan extractive industries is large, underserved, and increasingly visible to regulators. Banks want to grow this client segment but can't afford the manual overhead. Aggregators face compliance demands from buyers in Europe and North America that they can't fulfill at scale. And operators — who have assets, production, and real relationships — lack the documentation infrastructure to be taken seriously by formal institutions.
KOTA's engine runs one product across multiple institution types, adapted through configuration — not separate builds. Each new institution that deploys it is a high-margin contract, not a new development project. And the data the platform accumulates — operator profiles, verified documents, compliance histories — is the foundation of a future information layer the team is already mapping.
Connectivity, trust, regulation, language.
The operator using KOTA may be on a slow mobile connection, encountering formal due diligence for the first time, in a context where documented records barely exist. Every friction point in the operator-facing flow is a reason to abandon. The product has to be simple at a level business software rarely is.
Beyond usability: the product operates across DRC regulation, OECD guidance, and EU conflict minerals rules — each with different vocabulary. It runs in English and French. And the trust deficit is structural: operators have good reasons to distrust a system that collects sensitive data about their business. The two-copy data model — the bank inherits a copy when it edits, never mutating the operator's record — is one answer. The design is another.
Information Architecture
The question that split the architecture.
The brief had the bank side as a single landing: one view, every operator, registration and evaluation in the same place. What it didn't define was how responsibilities were organized inside it. Exploring the flow, I hit a question I couldn't answer: is the person who approves a registration the same one who runs the full evaluation later? I took it to the domain expert. The answer was no — different people, different moments in the bank's workflow. So I separated Registration and Evaluation into distinct areas, each scoped to its own task: its own forms, its own indicators, its own actions. One question, asked before any screen was final, reshaped the product's information architecture.
- Identity
- Legal form
- Documents
- Self-assessment
- Portfolio dashboard
- Registration record
- Customer summary
Editor populates · Custodian submits · Reviewer decides
- Own profile
- Applications
- Self-assessment
The Inputs
Nothing arrived as a design.
Three kinds of input shaped every decision — and each one required a different way of closing the gap between what was specified and what someone would actually see on screen.
A specification.
Workflows, rules, requirements. Precise about what the system does; silent about what anyone sees.
One-line briefings.
"There will be stages; at each one, a form and documents; then waiting; then an answer." That sentence was the entire brief for the application flow.
Spoken visions.
Features that lived in the founder's head, told in conversation, never written down.
The Method
Two loops closed every gap.
The question loop — for documents.
Read the spec, find what it doesn't say, formulate the question precisely, bring it to the domain expert — and listen for what the answer reveals beyond the answer. The questions were the research instrument; each one was a design tool, not a clarification.
The translation loop — for spoken visions.
Listen, write it down, propose a complete form, iterate together. Find Data — a capability the founder had wanted for years — reached me as a conversation. I proposed its entire form: the search surface, the sources, the acquisition flow. Then I scoped it down to what could realistically ship.
Navigation Grammar
One pattern carries every app.
The structure that made the split work isn't KOTA-specific. It's a grammar I created and refined across all of the platform's apps — and it held while I was away: engineering kept building inside it, and two years later the structure was still carrying the product.
The landing is always a table.
Every module opens on a list of subjects. No dashboards standing in for navigation, no guesswork about where things live.
Every subject opens into a hub.
A page I call Details: everything you can do with a subject at its current stage — forms, indicators, settings, paths to other stages — in one place.
Actions are stage-scoped.
What you can do follows where the subject lives. Inviting an operator or opening their summary only appears at evaluation, because that's where it makes sense.
The Product
The screens, carrying the decisions.
Each surface below makes one of the decisions above concrete. The gallery fills in as screens are exported.
Ownership
What was mine, and what wasn't.
The conceptual bets — operators registering themselves, the data model that keeps the bank's copy and the operator's copy separate, one engine serving two institutions, the scoring system — belong to the product's founders. I won't claim them.
Everything between those bets and a usable screen: the navigation grammar, the question that split the bank's workflow, the application flow built from one sentence, the form of Find Data, the discipline of states. That's the designer's layer — and on this product, it was mine.
Reflection
Rigor doesn't disappear without users. It relocates.
Working without user access doesn't excuse you from rigor; it moves the rigor into your questions — what you ask, who you ask, and how honestly you track what's still an assumption.
It also taught me what a domain expert can and can't give you. Mine could answer how a bank divides its work; he couldn't tell me how a first-time operator reads a progress bar. I designed those parts on judgment and pattern — and if I started today, I'd negotiate one round of user contact into the scope before the first screen. Not because the work is weak without it, but because one conversation closes gaps that two years of documents leave open.