Research & Prototyping

03

Find the riskiest assumption first

Every project has an assumption that, if wrong, kills the whole thing — the flow users will never adopt, the cost that never holds, the regulator who never approves, the API that never behaves. The first act of research and prototyping is naming that assumption precisely, because everything after it is about testing exactly that, and only that.

• The fatal assumption is identified — the one belief the entire plan leans on; usually it is about users, money or an external system, and rarely about the logo.
• It is stated falsifiably — 'tenants would pay rent through the app' becomes a claim with an observable test, not a sentence that can never be wrong.
• Everything else is postponed — features that only matter if the risky assumption holds are parked, so the research and the prototype stay small and fast.
• The failure we fear is named — what would prove us wrong, how it would show up, and what the 'no' looks like, are described before we start, not discovered after.
• Stakeholders are aligned on it — the founders, the board and the team all agree that this assumption is the one being tested this month; nobody is testing a different question.
• The cost of being wrong is priced — testing the assumption first is compared against discovering it late; the arithmetic is usually so lopsided it ends the argument.

The discipline of the risky assumption is what makes prototyping cheap: we never prototype the whole product — we prototype the one thing whose answer decides everything.

04

Discovery before the brief

Before any wireframe, discovery answers 'what is true here?'. Customer interviews, observation, market and competitor checks, existing-system analysis, and the hard look at whether the gap is real. Discovery is not a delay before work; it is the work that decides how much work is honest.

• Interviews on real behaviour, not claims — people are asked what they did last time, shown the last receipt, walked through the last process; claims evaporate, behaviour survives.
• Observation over testimony — where possible we watch the actual process — the counter transaction, the phone top-up, the reconciliation — because what people do and what they say they do differ.
• Market and competitor checks — the gap is tested against what already exists and what failed before; a gap that three startups already died in is a gap with a body count.
• Existing systems are read — the spreadsheet, the counter log, the WhatsApp flow the business runs today is the product already in production; it is read like code.
• The pain is quantified — how often, how long, how much does the current way cost; a pain nobody can measure is a pain that will not fund a build.
• The discovery ends in questions, not a deck — the output is the map of uncertainty with the riskiest assumptions marked, ready for the prototype to test.

Discovery is where the word 'platform' goes to die and the word 'problem' comes alive. The gap that looked like a product gap is often a message gap, a trust gap or a habit gap — and those are found in discovery at a fraction of the price of finding them in beta.

05

User research: what people actually do

User research is the difference between a product built for the persona in the pitch deck and one that survives the person actually in line at the counter. We research what people genuinely do, what they trust, what they fear and what they abandon — and we take the evidence as authority, not the loudest stakeholder.

• Interviews built on real events — recent-recall questions ('take me through last month's rent payment') produce behaviour; hypotheticals produce politeness.
• Usability sessions on real tasks — users are given actual tasks on a prototype and their path is watched; where they pause, misread or give up is the evidence.
• Diary and in-situ studies — the habit that research-labs miss — the phone shared with the family, the top-up done at the shop, the payment made at 10pm from the bicycle — is captured where it happens.
• Support conversations as a data source — the question asked a dozen times in the queue is a feature failure with a count; support tickets are qualitative research already in the building.
• Recruitment that matches the market — participants are the actual buyers and users in the Kenyan reality — prepaid data, shared devices, M-Pesa habits — not a convenient sample of the product-savvy.
• The findings are weighed, not counted blindly — one user's persistent, specific struggle outweighs ten users' vague comfort; signal matters more than headcount.

On money products, research is doubly careful — because a flow users misread is a flow users pay wrong, and a trust break is a refund later. We research the money journey with the respect that its mistakes get paid for in cash.

06

The Kenyan user reality

Products built for a sanitized lab fail the market that actually pays. Our research and prototyping treat the Kenyan reality as a first-class constraint, because a prototype that ignores it tests the wrong hypothesis: the one about an imaginary user with infinite data and a flagship phone.

• Prepaid data is the default — every megabyte costs money, so a flow that is heavy, image-saturated or chatty is a flow users abandon on principle; the prototype tests weight.
• Connectivity is clever, never guaranteed — the network drops, flaps and switches; a money flow that dies on a dropped connection is a prototype fail that no lab network reveals.
• The phone is shared — one device is used by a household; identity, privacy and the lock screen are not lab considerations, they are everyday ones.
• M-Pesa is the muscle memory — the STK push, the pin, the 'Lipa na M-Pesa' and PayBill habits are how money actually behaves; a prototype that fights that muscle memory is testing stubbornness, not usefulness.
• Trust is built slowly and lost once — the user who lost money once does not return for a second test; the prototype must be honest about where money goes, visibly.
• English may be the second language — wording, not just screens, is tested; the concept clarified in plain terms is measured just as carefully as the click-through.

When we prototype a payment flow, we test it the way it will truly run: on an entry-level phone, on a patchy network, in the words a user actually carries. A prototype that passes a lab and fails Juja or Nakuru tested the wrong proposition.

07

What a prototype is for

A prototype is not a pitch prop. It is a machine for getting honest reactions: it makes the idea concrete enough that a user can do something with it, and what they do — the path, the hesitation, the question, the error they actually make — is the data. The goal is not approval; it is behaviour.

• It makes the abstract feel real — a concept described in a meeting gets polite nods; the same concept shown as a screen gets a pause, a frown, or a 'wait, is that the amount?'.
• It costs days to make a mistake impossible to ignore — the flow that reads oddly on paper, or the copy that reads like a robot, is seen in use, not in review.
• It is deliberately narrow — the prototype contains exactly the hypothesis being tested; beauty, colour and completeness that distract from the question are edited out.
• Users react to the doing, not the typing — participants are given tasks and their behaviour is watched; their compliments are ignored, their hesitations are recorded.
• It teaches the builders as much as the users — the questions a prototype raises ('what happens if she cancels here?', 'why did nobody touch that?') are findings too.
• It comes back for another round — the first prototype is not the last; the plan is several fast rounds, each cheaper and each smarter than the last.

The moment a user says 'oh, I thought this button did that' is the moment a prototype earns its cost. A session like that is a bug report about the product as an idea — and it costs a day, not a release.

08

The technical spike: prove the risky part works

Some risks are not about users at all — they are about technology. Does the gateway actually return what the documentation promises? Can the flow survive the network reality? Does the integration behave at the volume planned? The technical spike answers those by building only the uncertain part, against the real thing, and reporting evidence instead of hope.

• The uncertain API is actually called — sandbox keys are registered, the real flow is exercised and the response is read; documentation is treated as a rumour until verified.
• The spike is scoped to the uncertainty — the goal is one answer (does this work? does it hold? does it cost what we think?), not a vertical slice of the whole product.
• For money, the spike is done in the sandbox — the Daraja and M-Pesa test environment at home, and every other gateway's test keys and simulated callbacks beyond it, are the rehearsal stage for what will then be repeatedly verified in production.
• The real constraints are rehearsed — latency, retries, timeouts, the callback that arrives twice and the callback that never arrives; the spike tests the failure shapes the docs skip.
• The verdict is evidence, not enthusiasm — the spike report states what was attempted, what returned, what failed and what it proves; whether that proves a go or a no is reported straight.
• It leaves artifacts, not only anecdotes — the working code, the authenticated integration, the observed numbers become the seed of the real build or the reason it never happens.

The spike is how 'we are not sure the gateway will cooperate' becomes 'the gateway returns exactly X on these inputs'. On money paths especially, the spike is the cheapest insurance there is: call the real thing, in the sandbox, before the budget commits.

09

Throwaway versus production path

Every prototype eventually faces the question: does this become the product, or was it fuel for learning? We are explicit from the start about which path the prototype is on — a throwaway prototype is built to be thrown away with no apology, and a production-path prototype is built with the discipline that it will carry real weight. Confusing the two is how companies ship demos and then drown in them.

• The path is declared up front — the stakeholder knows whether this artifact is fuel or foundation; nobody is surprised at month four.
• Throwaway is not shameful — a spike that answered its question and is deleted did the most efficient job possible; keeping it beyond its purpose is the waste.
• Production path carries the discipline — the seed that will grow must already hold the real decisions: the data model, the auth, the money paths, the failure handling.
• The graduation is a decision, not a drift — a prototype graduates to product only at a named moment, with a review of what must change in transit; nothing creeps.
• The rename is managed — when a spike becomes the seed, the shortcuts taken for speed are listed and scheduled for repair; they are not inherited silently by the real system.
• The honest default — most seed prototypes graduate smaller than their creators hoped: the research cut the scope while everything was still cheap, which is the entire point.

We have thrown away prototypes we loved and grown ones we doubted — the decision was always about the evidence, never the sunk cost. A prototype knows its destiny: fuel, or foundation — and the honest naming of that is a service to every hour that follows.

10

Fast validation: the discipline of small, quick, honest rounds

The value of prototyping decays as it slows down. A round that takes two weeks produces decisions at the speed of meetings; a round that takes two days produces decisions at the speed of learning. Fast validation is not cutting corners — it is the discipline of asking the smallest question that produces an honest signal, running it, and learning before the market question goes stale.

• The smallest honest test — a paper flow, a clickable few screens, a false-backend prototype; whatever answers the question with the least machinery that still produces a real reaction.
• Rounds measured in days — each cycle frames the question, builds the minimum, observes the users and writes the verdict within days — not within a sprint deadline.
• One question per round — a week's fast round answers one uncertainty deeply instead of five shallowly; the questions stack, the rounds compound.
• Low fidelity is a feature, not a shortage — a rough screen hides less than a polished one; users critique the idea when it looks unfinished, and compliment it when it looks done — we want the critique.
• The failures are scheduled so the market is not — the no that costs two days of prototype is a bargain compared to the no that costs six months of build; speed is how the market question stays current.
• Every round ends with a written verdict — what was asked, what was seen, what it means, what is next — so the discipline does not die when the mood changes.

We prototype at the speed of decisions because the market question does not wait for a dashboard's approval. A fast round that produces a humble no is a better week than a slow project that produces an expensive maybe.

11

The prototype is not a product

This is the line we repeat until it is boring: a prototype validates an assumption; a product carries a promise. The demo that impressed the board is not the system that serves a hundred thousand users — and the honest scoping between them is exactly why prototyping exists. We keep the line at every engagement, because it protects the client from the most common and expensive confusion in software.

• A prototype answers a question — it proves a flow, an appetite or an integration; it does not prove that reliability, security and scale will follow, and it should not be asked to.
• A product carries a promise — uptime, privacy, money moving exactly once, support answering, ten thousand users still fast; the gap from prototype to promise is the real build.
• The diagram scares no one — telling a board 'the prototype is a small fraction of the product' is not selling ourselves short; it is saving them from the demo-to-disaster gap.
• Research findings scope the build — the prototype's value is the evidence that the real build should be bigger here and smaller there — not the blueprint the build must follow line by line.
• The polished demo is the dangerous moment — when a prototype looks finished, stakeholders assume the finish is almost free; we name that cost early and honestly.
• The line protects the team — an engineer told 'make the prototype production-safe' while prototyping is being asked to pay a production price for validation value; the roles are kept clear.

The most expensive sentence in software is 'the prototype was the easy part'. We say it to clients because it is true, and we say it loudly enough that the budget left standing after the prototype still respects the real build.

12

Evidence, not enthusiasm

A great idea with no evidence is a bet; an idea with signals is a plan. Everything in our research discipline bends toward weighing signals from real users and real systems honestly — including the signals that disappoint the room. Enthusiasm is the enemy of validation, because it is the engine of confirmation bias.

• Signals are gathered from reality — behaviour in sessions, counts in analytics, questions in support, responses from the real API; the evidence has an address in the world.
• The contrary is sought actively — we look for the users who fail, the flow that breaks, the message that confuses; the no is as much a finding as the yes, and often a cheaper one.
• Neutrality is engineered — the prototype is introduced without sales framing ('this is a rough test, it is supposed to have holes') so politeness cannot masquerade as validation.
• The verdict is written, not felt — after every round the evidence is summarised in a line that stands on its own: what was observed, what it implies, whether it supports the plan.
• Numbers get planning ranges — when the question is cost or realism, the estimates carry ranges and reasons; the marketing number is refused politely and firmly.
• The uncomfortable go/no-go is honoured — when the evidence says no, the recommendation is a no, with the evidence attached; protecting a favourite idea is not a consulting service.

We have ended projects on evidence and we have accelerated them on evidence; both felt uncomfortable in the room and both were right in the balance sheet. Enthusiasm is the fuel, but evidence is the map — and the map is the one the road actually follows.

13

Go/no-go: the decision delivered as evidence

The research and prototyping arc ends in a decision: go, with this scope and these risks — or no, and that is the product's finest hour. We deliver the go/no-go as a documented verdict with the evidence attached, so the decision survives the meeting where it was made and the people who have to live with it.

• The go is scoped by what was proven — the go recommendation says what the evidence supports building, what must still be de-risked and what the prototype did not prove.
• The no is delivered with its evidence — the interviews, the sessions, the integration results that killed the idea travel with the verdict, so the no is persuasive and portable.
• The decision is the client's, always — we deliver the evidence and the recommendation; a client who proceeds against our no does so with eyes open, and our work does not insult them for it.
• The options carry ranges — where the question is partly judgement, the honest paths are presented with their costs; the decision-maker chooses, we do not decide for them.
• The exit is clean either way — a concluded no is a finished, successful engagement; we do not manufacture a go to keep the project alive, and the client knows it.
• The evidence is archived — the research survives the decision, so next year's team can re-read why the scope is what it is instead of reinventing the reasoning.

A well-run no is a career's most valuable day of work. The project that never happened because the evidence said so is the project the budget will silently thank you for, every single month.

14

From prototype to build: the documented basis

The last deliverable of research and prototyping is not a prototype — it is the documented basis: what was tested, what was learned, what the build scope should be, and which risks were retired or remain. That document is what lets the build start fast instead of rebooting the questions, and it is what keeps the research from evaporating when the team changes.

• The scope is written from evidence — the build is scoped to what the research supported; the feature that the sessions quietly rejected is absent and there is a reason on file for its absence.
• The risks are carried forward — what the prototype could not prove is listed with a plan to retire it early in the build, not discovered late in it.
• The decisions are recorded — the go/no-go, the throwaway-versus-production choice and the scope cuts all live in a decision record a fresh team can re-derive.
• The handover is concrete — the prototype, its code where it exists, the research artifacts and the findings change hands as an asset, not as a memory.
• The build starts on the fastest path — with the risky parts de-risked, the engineering starts on the core loop instead of spending its first sprints redoing the research.
• The loop is not closed, it is continuing — the build is instrumented to keep gathering the signals, so the research habit becomes the product's standing discipline.

The prototype that de-risked the build is only as good as the notes that survive it. We hand over the evidence with the same care we hand over the code — because what a future team knows about why shapes what they build next.

15

Prototyping money flows: the sandbox is the stage

When the risky part is a money flow, prototyping has particular rules: the real gateways — Daraja and M-Pesa at home, and every other rail the flow will touch beyond — are met in the sandbox, the callbacks are simulated the ways the real internet delivers them, and the verification loop is rehearsed before real money moves. The discipline that protects a payment platform in production starts in the prototype stage — because a money flow prototyped carelessly teaches the wrong lessons.

• Sandbox keys are the rehearsal stage — the Daraja/M-Pesa test environment stands in for the live rail alongside every other gateway's sandbox, and the flow is exercised with test paybills, test tills, test cards and simulated callbacks.
• Callback failure shapes are rehearsed — a callback that arrives twice, a transport error, a verification that disagrees — the prototype runs the shapes the docs describe so the real thing is not the first time.
• The verification habit is born early — even in the sandbox, a callback is treated as a claim to be checked against the gateway's own status API; the habit transfers directly to production.
• The pending experience is prototyped — how the user sees 'waiting for confirmation' on whatever rail, be it the M-Pesa push, the card charge or the bank transfer, how retries and timeouts read, is a user-experience question with money in it; it is tested like one.
• The 'where is my money' path is rehearsed — how the user finds out what happened to their payment is prototyped with the same care as how they pay — because support answers are a product feature.
• The economic assumption is tested, not assumed — fees, float, unit costs and the reconciliation shape are checked in the prototype economics, so the business model is validated beside the flow.

The sandbox faked nothing about our own money platform's hard lessons — it taught us the flow; production taught us the discipline. We prototype money flows so that production never has to teach the discipline at a customer's expense.

16

When prototyping is the wrong tool

Honesty cuts both ways: prototyping and research are not always the answer. Some assumptions cannot be de-risked by a prototype, some products are already validated by the market, and sometimes the honest answer is that the team knows enough to build and measure in production. We say so when a prototype would be ceremony.

• Some risks only reveal in reality — adoption, retention and unit economics often have to be tested by a shipped product with measurement wired in; a prototype cannot fake a year of usage.
• Research is not a substitute for judgement — when the evidence is in and the founders still disagree, another prototype is a delay dressed as diligence; the decision then belongs to leadership.
• Existing demand cuts both ways — a market that is already queueing for a product may not need another validation round; it needs the build, safely, now.
• Prototyping heavy things is pricey — at some point a prototype costs a meaningful share of a build; the honest call is to build the smallest real thing and iterate on live usage.
• False precision is a risk — a workshop full of people who already want the product produces a yes wearing the costume of research; we are candid about when the sample is not a sample.
• The client's appetite is respected — a client who genuinely wants to skip discovery, with eyes open and a tolerance for the wider range, gets an honest warning and the smaller-scope build that follows.

We would rather tell a client that the prototype is unnecessary this time than sell them a theatre of diligence. The discipline is not a ritual; it is a tool for risk — and the honest tool-user knows when the tool is not needed.

17

How we research and prototype

The arc is short and disciplined: frame the question, find the riskiest assumption, gather the evidence, build the minimum, test with real people, weigh the signals, deliver the go/no-go, and document the basis the build stands on. The shape is the same for a financial product and a consumer app — only the stakes and the sandboxes differ.

• 01 · Frame the question — the decision in front of the client, in a sentence, and the assumptions it rides on.
• 02 · Find the riskiest assumption — the one belief whose failure kills the plan; everything else is parked.
• 03 · Gather the evidence — interviews, observation, market checks and the existing system read with respect.
• 04 · Design the smallest honest test — the fewest screens, the narrowest spike, that still produces a real reaction.
• 05 · Build the minimum — the prototype or spike scoped exactly to the question, in the sandbox where money is involved.
• 06 · Test with real users, on real tasks — behaviour watched, hesitations recorded, compliments politely ignored.
• 07 · Weigh the evidence honestly — the contrary sought, the signals written down, the verdict forced into a line.
• 08 · Deliver the go/no-go — the evidence attached, the recommendation clear, the decision handed back.
• 09 · Document the basis and wire measurement into the build — scope, retired risks, remaining risks and decisions recorded so the build starts fast and honest, and instrumentation keeps the research habit standing after v1.

The research, the prototype, the findings and the decision are yours — with no hostageware that keeps the learning with us. What we hand over is the ability to know: what was tested, what was learned, and what the evidence says next.

The toolchain

The research & prototyping toolchain

Research and prototyping are evidence work: the tools exist to gather real behaviour, build the smallest honest test, and weigh the signals into a decision. Every capability below serves the same goal — a go/no-go the budget can bank on.

Lifecycle

The research & prototyping lifecycle — from question to documented basis

Every engagement runs this arc, sized to its question: frame, test the riskiest assumption, weigh the evidence, and hand the build an honest starting point. The same arc disciplines our own product work, including the money flows on our live platform.

Closing

More than development

Research and prototyping exist to meet the risky assumptions while they are cheap — with user research that finds what people actually do and prototypes that make the idea real enough for honest reactions. That includes:

A great idea with no evidence is a bet; an idea with signals is a plan. Research finds the signals, and the prototype tests them at the cheapest possible price.

We would rather hand you a humble no from a two-day test than a confident maybe from a six-month build — because the no costs you a prototype, and the maybe costs you a product.