A sponsor deciding whether to fund a farm. Money stuck between wallet and bank. Four people sharing authority over one balance. A kitchen waiting on payment. An AI score that cannot verify itself. These are six decisions from the work, and the evidence behind them.
Each one is a problem, a decision, a frame from the product and a governed result, with the study that carries the rest.
Decision 01
What a first-time sponsor needed to know before funding a farm they might never see
Farmcrowdy · first design hire · 2017–2020
The problem
Farmcrowdy asked urban Nigerians to commit money to a farm they could not inspect, run by a farmer they would not meet, for a return that arrived after a growing cycle. The old public page opened on a video and a row of unlabelled illustrations before it answered the questions a careful person asks first: who else is doing this, what protects the money, and what happens between payment and harvest.
The decision
Rebuild the mobile sponsorship journey in the order of the sponsor’s questions rather than the order of the funnel: which farm, what return, over what cycle, and what happens to the money in between. The first run explains what sponsorship does for the farmer and for food security before it shows the sponsor’s own return, and the redesigned public page states the proposition, who else is sponsoring and what protects the money before it asks for anything.
The first run, live: click a screen to enlarge it. The sponsor’s own return is placed third, after the other two. Redrawn from the shipped product with representative data.
18% → 60% first-time sponsorship conversion
Direct outcome of the mobile sponsorship redesign, from the governed Farmcrowdy record.
A stablecoin-to-Naira transfer crosses a crypto asset, a moving rate, a fee, a Naira payout and a bank’s own settlement state. A sender shown a hash, a gas figure and a confirmation count cannot tell whether the money is delayed, failed or gone, and a bank that is slow looks identical to a product that is broken.
The decision
Make every state a sentence a sender can act on. The quote shows the rate, the fee and the exact Naira the recipient gets before anything is committed; after sending, three technical events become three plain-language lines, elapsed time is the only number on the screen, and pending, failed and recovery are distinct states rather than one spinner.
The Sent screen: a trail, not a hash. Three technical events become three sentences a sender can read without knowing what a chain is. Redrawn from the shipped product with representative data.
Authority over money had to be modelled before any screen was drawn
Earlybean · co-founder & product lead · 2020–2026
The problem
A child-facing savings app could teach the mechanics of saving but gave families limited ways to apply them with real money, because four parties had a claim on that money: the parent funding it, the child spending it, the school overseeing its environment and the merchant receiving it. Each of their needs belonged to a different party, and none could be resolved inside a child-facing app.
The decision
Model the permissions first as three relationships that run in different directions — money movement, parental authority and school oversight — and derive every screen from that model. Funding, approvals, limits, visibility and blocking stay separate parent controls; a child owns a real identity inside limits someone else set; direct spending is bounded to approved environments; and a decline at a till names the rule that stopped it and who can lift it.
The four-actor model, live: switch between money, authority and oversight. The dotted boundary is the reason direct spending stays inside approved environments.
Shipped: parent-controlled child accounts, savings goals, card and wristband spending, transfers, school onboarding and the merchant application
The architecture is the proof here; the platform’s July 2026 snapshot stays in the case study with its provenance.
An administrator preparing a Kolibri deployment might have an hour of internet, a school server down the corridor or a USB drive from a partner, and the earlier product treated each as a different screen with different rules. People lost confidence at the entry point, could not judge storage cost before a download, could not tell an update from a new import, and did not know what to do when a long transfer failed halfway.
The decision
Re-architect import as one acquisition system with one logic for every source. Discovery, preview, partial selection, storage, versioning, progress, failure and recovery share a model; the source only changes the constraints it exposes. A dropped connection holds the progress bar where it was and offers resume rather than resetting, because the transfer, not the catalogue, is the design problem.
The connection drops, the bar holds its position instead of resetting, and the banner offers the only action that matters.
+85% discoverability · −60% failed imports, in usability testing
Usability-testing outcomes for the redesigned flow, not production telemetry.
A direct or WhatsApp order should not become kitchen work until its payment state is satisfied
Lion Hospitality Partners · head of product & technology · 2026–present
The problem
Orders reached a 14-venue group from the counter, a delivery marketplace, WhatsApp and a direct storefront, and the same order then moved through payment, the kitchen, stock and dispatch. The work was keeping those states aligned during live service, starting with the first one: when an order is allowed to become kitchen work.
The decision
One order-state model for every channel, and payment-gated release: an order becomes kitchen work only once its required payment state is on it. At the counter the send action stays inert until a payment method is chosen; direct and WhatsApp orders are likewise held out of the kitchen until payment is confirmed, and marketplace orders enter the same shared order-state model. An order cannot reach completed without passing the ready-for-handoff checkpoint the inventory model depends on, and every exit — cancelled, voided, part ready — names who acts and what the guest is told. The existing order-state model, reused, rather than a new system per channel.
An order line cannot reach Completed without passing the ready-for-handoff checkpoint the inventory model depends on, and every exit from the path names its consequence. Labels are written for staff, not as system codes.
14 venues · 15,402 paid orders in the first 15 weeks
Current operating scale from the governed record; no dispatch-time or variance figure is claimed.
Model output cannot grade itself; acceptance had to be tested against labelled external truth
ApplyOS · independent design/build · 2026–present
The problem
A language model will score a role it cannot verify, narrate a rejection it did not make, and write an application answer citing experience the candidate does not have. The first working version scored each role with one model call that returned a number and a sentence of reasoning; it demoed well and was unfalsifiable, because the same role scored differently across runs and nothing outside the model could say whether a score was right.
The decision
Move judgement out of the model wherever a person can inspect it instead. Eligibility resolves by deterministic rules before fit is scored; scoring is reproducible from rules that can be printed; answers are assembled from a governed evidence registry the model selects from but does not phrase; and acceptance runs against a hand-labelled set of roles and captured real-form state, not against the model’s own confidence.
Stage
Who decides
Checked against
Eligibility
Deterministic rules
Hand-labelled roles
Fit scoring
Rules over extracted fields
Same labels, every run
Answer drafting
Model, from a governed registry
Registry provenance shown to the candidate
Submission
The candidate
Captured real-form state
Where judgement lives, and what each stage is tested against. Nothing in the system grades itself.
171 hand-labelled roles · feed precision 59% → 89% after market-aware gating · 256-test verification suite
First-cohort calibration evidence against labels I wrote — the system’s retrieval quality, not an employment outcome.
Read the work by project, or by the lane you hire for.
The case studies carry the research, the states and the frames behind each decision. The two role views order them for a financial-product team or a platform team.
