Building Technology In A Difficult Environment

The first version of the product worked perfectly. It worked perfectly on fibre broadband, on a recent phone, with a card that a bank would authorise. In other words, it worked perfectly for almost none of the people it was built for.

"We built for the demo," he says. "The demo audience was investors and other founders. Our actual users were on a 3G handset in a market in Aba with 8% battery."

Rebuilding around that reality took two years and produced a company that, by his own account, is far less elegant and vastly more durable.

**Constraints as specification**

He talks about the environment not as an obstacle to route around but as the specification itself.

Power. Diesel, inverters, and a duty cycle you plan around. Every deployment assumes the office loses grid power daily. Nothing critical runs on a machine that requires someone to be physically present.

Connectivity. The app is offline-first, not offline-tolerant. Transactions queue locally and reconcile. "This one decision doubled retention. Not a feature — a failure mode we stopped punishing users for."

Currency. Pricing is reviewed quarterly and revenue is partially dollarised through export customers. He learned this the hard way, absorbing a devaluation that erased a year of margin. "You are not running a startup and a treasury desk. You are running a treasury desk that happens to have a product."

Payments. Cards were never going to be enough. Bank transfer with automated reconciliation, agent cash-in, and USSD fallback. Three rails, because any one of them will be down on a given Tuesday.

Talent. His best two engineers were recruited by a European company within eighteen months. He now assumes a three-year ceiling and builds documentation, pairing and internal training on that assumption rather than resenting it. "You cannot out-pay London. You can out-teach it."

**The part that has nothing to do with technology**

Regulation moved twice during the build. Import duty changes reshaped one customer segment overnight. A logistics partner failed in a week.

"Elsewhere you plan for market risk," he says. "Here you plan for environment risk, and market risk sits on top of it. Your buffer cannot be a number in a spreadsheet. It has to be a design principle."

The practical version: no single point of failure that lives outside the company. Two payment providers. Two cloud regions. Two people who understand every critical system. It is expensive. It is also why they are still trading.

**Why he stayed**

He has been asked repeatedly why he does not relocate the company. The answer is not sentimental.

"The constraints are the moat," he says. "A team that has solved offline reconciliation, three payment rails and a 40% currency move can operate anywhere. A team that has only ever built on fibre with Stripe cannot operate here. The difficulty is doing the selection for us."

He is wary of the heroic framing that gets applied to African technology stories. "Nobody needs to admire us. We would prefer stable power and predictable policy. But you build with the environment you have, and the environment you have becomes what you know."

**What he would tell someone starting**

Design for the worst plausible day, not the average one. Price in the currency your costs are in, if you possibly can. Assume your best people will leave and make that survivable. Build two of anything that can stop the company.

And measure success in survival years first. "Growth here is not a curve," he says. "It is a sequence of years you did not die. String enough of those together and you look, from outside, like an overnight success."