Lessons from Scaling to 87,000 Users

When I took over BantuPay as Technical Product Owner, it was a blockchain wallet with a small user base, a team with big ambitions, and a product that needed to become something significantly more usable than it was.

By the time I left Bantu Blockchain, BantuPay had 87,000 users across 147 countries and had processed over $23 million in transactions. We'd also launched Timbuktu, a KYC-light decentralised exchange, which reached 7,400 users in a short window.

I want to be careful about overclaiming here — growth is always a team effort, and I'm one part of a larger story. But I was close enough to the product decisions that drove that growth to share what I learned. Here's what actually mattered.

The Error Rate Discovery That Changed Everything

When I first got deep into the data on BantuPay, one number stopped me: 15% of transactions were failing.

Not abandoned. Failing. Users were initiating transfers, going through the flow, and hitting errors before the transaction completed. At scale, that's a catastrophic figure. In payments, a failed transaction isn't just a bad experience — it's a trust event. Users who experience a payment failure once are significantly less likely to try again. If 15% of your transactions fail, you have a leaky bucket that no amount of user acquisition will fix.

When I dug into the cause, it was almost embarrassingly simple: wallet addresses. Blockchain wallet addresses are long strings of alphanumeric characters — 42 characters in some formats. Users were copying them from one place, pasting them into another, and making errors. One character wrong and the transaction fails. Sometimes the funds end up somewhere unintended. Often they're just lost.

The fix was the username-based transfer system. Users register a unique username — like a handle. Instead of sending funds to 0x3f5CE5FBFe3E9af3971dD833D26bA9b5C936f0bE, you send them to @uche. Server-side, the system resolves the username to the wallet address before the transaction executes. The user never touches the raw address.

We went from 15% transaction failure to 2%. That single change probably did more for BantuPay's growth than any marketing initiative.

The lesson: know your core failure metrics before you know anything else. The leaks in your product are more important than any new feature you want to build.

Cross-Border Complexity Is Real and Mostly Underestimated

147 countries sounds like a growth story. It is. But it's also a compliance story, a localisation story, and an infrastructure story that doesn't end.

Serving users across that many jurisdictions means different regulatory requirements in different markets. Different expectations around KYC. Different levels of trust in blockchain as a payment mechanism. Different connectivity constraints affecting how reliable the product needed to be on low-bandwidth connections.

We weren't always compliant in every market at every moment — the regulatory landscape for crypto and digital wallets during this period was genuinely fast-moving and inconsistent across regions. What it required was staying close to the regulatory picture, being honest about what we could and couldn't support in different markets, and building in a way that made compliance additions possible without architectural rewrites.

The product lesson here is about building for context diversity from the start. If your product serves a narrow, homogeneous user base, you can make a lot of assumptions. If it serves people across different economies, infrastructure realities, and regulatory environments, you need to build those variables in rather than treating them as edge cases.

Simple Is a Strategy, Not a Shortcut

One of the pressures I felt consistently in the BantuPay context was the temptation to add complexity. Blockchain products carry a certain expectation of feature density — DeFi integrations, staking, yield products, trading features. Users might want these things. Competitors were building them.

But every time I looked at the data, the answer was the same: the core experience wasn't simple enough yet. If users are still failing to complete basic transfers, adding a staking product doesn't grow the platform — it distracts from fixing the thing that matters.

The discipline of saying "not yet" to features that would dilute focus on the core experience is genuinely hard. It requires having enough data to make the case, enough credibility to win the argument, and enough conviction to hold the line when the pressure is to move fast and add things.

The simplicity principle we operated on: if a new user couldn't understand the core value and complete a core action within their first session, we hadn't earned the right to build the next thing yet.

Timbuktu: What a 7,400-User Launch Teaches You About Growth vs. Readiness

Alongside BantuPay, we launched Timbuktu — a decentralised exchange designed to be accessible without full KYC requirements. It was a different product with different users and different regulatory considerations.

The launch was fast. The growth was real. 7,400 users in a short window is meaningful for a DEX in a niche ecosystem.

What it also was: a lesson in the difference between growth and readiness. We grew faster than our infrastructure and compliance framework were prepared for. Not catastrophically — we didn't have a breach or a major failure — but the experience of managing rapid early growth when parts of the product were still being built in parallel is a kind of productive chaos that teaches you a lot about prioritisation under pressure.

The honest takeaway: early growth is intoxicating and it's easy to let it pull resources and attention away from the structural work that makes growth sustainable. The best product decisions I made during that period were the ones that said "the growth is great, and we still need to fix this foundational thing before it breaks under the weight."

What I'd Tell Someone Building for Scale

Instrument everything from day one. We got better at measurement as we grew, but some of the early data gaps cost us time. Knowing your retention curves, your activation rates, your core action completion rates, and your failure points from the beginning changes what you build and when.

Trust compounds slowly and breaks fast. In payments especially, every bad experience is disproportionately memorable. A failed transaction that costs a user £5 can cost you that user permanently. Every product decision should be evaluated against its impact on trust, not just its impact on engagement metrics.

Your first 1,000 users are a different product than your next 10,000. What works to acquire and retain your early adopters — often people who are willing to tolerate friction because they believe in what you're building — doesn't scale to a broader audience. Plan for the transition before you're in it.

Localisation is not translation. Making a product work across 147 countries isn't about translating your UI. It's about understanding what people in different contexts actually need, what they trust, and what friction means for their specific situation. The more genuinely you engage with context diversity, the more of your product's potential you unlock.

87,000 users is a number I'm proud of. But the thing I actually learned building to it isn't really about scale. It's about the discipline of staying close to what matters — the core experience, the failure points, the trust signals — when the pressure is always to move on to the next thing.

That discipline doesn't get easier with scale. If anything, it gets harder. But it's the thing that makes growth meaningful rather than just fast.