Why We Ask "Why"
Five Years Engineering Economic Inclusion for Africa
Platform engineering begins with one question.
Five years ago, we took on an engagement that most product shops would have passed on. A client approached us with a vision: build a platform for Africa that would bring social networking, marketplace commerce, day-to-day lifestyle services, and safety into a single app. Not a payments app. Not a mobile wallet. A comprehensive Super App that could transform how half a billion people participate in the digital economy.
The scope was ambitious. The infrastructure constraints were severe. The timeline was indefinite—measured in years, not sprints.
We said yes. And that decision taught us more about platform engineering than any other project in our 19-year history.
This is the story of KeyZane—a Super App now live in Central and West Africa with over 100,000 downloads. But more than a case study, this is about what we learned. About the difference between executing requirements and creating platforms. About why the most important question in product engineering isn’t “how” but “why.”
The Problem Worth Solving
Over 500 million Africans lack access not just to financial services, but to the broader digital economy. They’re excluded from the systems that enable savings, payments, credit, commerce, and economic participation. Traditional banks can’t profitably serve these populations. The infrastructure doesn’t exist. The economics don’t work.
But something else does exist: mobile phones. By 2030, an estimated 90% of sub-Saharan Africa will own smartphones. That’s not a technology trend. That’s a platform opportunity.
When our client came to us, they didn’t have a specification. They had a vision far broader than financial services: bring Social Market Network, day-to-day lifestyle, and Anti-collision in a single App—empowering a safer, more connected, and economically inclusive world. Connect diaspora communities sending money home. Enable small businesses to participate in digital commerce. Create pathways to economic inclusion that don’t require traditional banking infrastructure. Build safety into everyday digital interactions.
The question wasn’t whether this was technically possible. The question was whether we could build a platform flexible enough to serve use cases that didn’t exist yet—in an environment where everything we took for granted (reliable connectivity, modern devices, stable regulatory frameworks) couldn’t be assumed.
Why "Why" Matters More Than "How"
Most software projects start with requirements. Client provides specifications. Engineering team estimates effort. Development begins. This model works when the problem is well-defined and the solution is understood.
Platform engineering is different.
When you’re building something that needs to evolve over years—serving use cases that will emerge from real-world usage—starting with “how” is a trap. You’ll build exactly what was specified. And you’ll spend the next several years rebuilding it as reality diverges from the original plan.
We learned early in this engagement to start every conversation with “why.”
Client: “We need user profiles.” Us: “Why?” Client: “So users can identify themselves.” Us: “Why do they need to identify themselves?” Client: “To transact with each other.” Us: “What kinds of transactions? Between what kinds of entities? Will a person transact differently than a business? Than a government agency?”
That line of questioning led us somewhere the original requirement never contemplated: a platform built around entities that can be anything—individuals, businesses, community groups, government agencies—with the ability to switch context and interact across entity types.
A user might be a person sending money to family. That same user might also run a small business selling goods. That same user might interact with their municipal government for services. One identity. Multiple contexts. Fluid interactions.
If we’d built “user profiles,” we would have built a payment app. By asking “why,” we built a platform capable of hosting an ecosystem.
The Architecture of Flexibility
The technical decisions that matter most in platform engineering aren’t about which frameworks to use. They’re about what assumptions you’re willing to hardcode.
We made a foundational choice early: build the entire platform around relationships between entities, not around fixed user types. This architectural approach—powered by KeyZane’s patented ORP (Operations Resource Planning) Technology—creates a virtual reflection of the real world where people, businesses, sites, communities, cities, and government entities interact multi-dimensionally and share resources globally.
This meant designing data architecture that could express any relationship—person to business, business to government, community to individual—without requiring code changes to enable new interaction patterns.
This decision had consequences. It made early development slower. It required more upfront thinking about edge cases. It meant building infrastructure that seemed over-engineered for the initial use cases.
But it also meant that when the client said, “We want to add micro-lending,” we didn’t rebuild. When they said, “Businesses should be able to create marketplaces,” we didn’t redesign. When they said, “Government agencies should connect with constituents,” we didn’t start over.
The platform absorbed new capabilities because the architecture assumed new capabilities would emerge.
This is what separates platform engineering from project execution. Projects optimize for known requirements. Platforms optimize for requirements that don’t exist yet.
Building the Operations Backbone
A mobile app is what users see. But platforms require something users never see: the operational infrastructure that keeps everything running.
Early in the engagement, we faced a choice. We could integrate off-the-shelf back-office products—CRM systems, operations dashboards, compliance tools—and spend years fighting their assumptions about how financial platforms should work. Or we could build a purpose-designed operations platform that matched the flexibility of the mobile experience.
We chose to build.
The result is what we call the Operations Console—a comprehensive web application that handles everything required to run a financial services platform at scale. Customer relationship management. KYC verification workflows. Transaction monitoring and dispute resolution. Wallet administration. Marketplace oversight. Compliance reporting.
Every feature in the mobile app has a corresponding operational capability in the Console. When users complete KYC verification, operations staff review and approve through purpose-built workflows. When transaction disputes arise, resolution teams have full context and audit trails. When new entity types launch—a government agency, a community marketplace—the Console adapts without requiring new integrations.
Building this from scratch rather than assembling vendor products added development time. But it gave us something off-the-shelf solutions couldn’t: operational infrastructure that evolves with the platform rather than constraining it.
This is an underappreciated aspect of platform engineering. The visible product gets attention. The operational backbone determines whether the platform can actually run in production. We’ve seen platforms fail not because the app didn’t work, but because operations couldn’t scale. By treating the Operations Console as a first-class engineering effort—not an afterthought assembled from third-party tools—we built a platform that can actually be operated.
Building for Constraints That Expose Everything
Africa’s infrastructure constraints aren’t obstacles to work around. They’re design requirements that expose every weakness in your architecture.
Connectivity is intermittent. Bandwidth is limited. Device capabilities vary dramatically. Users might start a transaction on a bus with strong signal, lose connection in a tunnel, and expect the transaction to complete when they emerge. They might use devices three generations behind current releases. They might have data plans measured in megabytes, not gigabytes.
Building for these constraints forced engineering discipline we wouldn’t have developed otherwise.
We implemented offline capabilities for non-financial operations—allowing users to browse, communicate, and prepare transactions without connectivity, then sync when signal returned. We optimized every payload for size. We tested on devices we would have ignored in other markets.
And we learned something important: if your platform works in Central and West Africa’s infrastructure environment, it works anywhere. The constraints that seemed like limitations became proof of engineering quality.
When we tell prospective clients “we’ve built production systems for challenging infrastructure environments,” we’re not speaking theoretically. We’ve shipped. Users depend on it. It works.
Five Years of Evolution
Platform engineering isn’t a phase. It’s a commitment.
Year one was about proving the concept. We built a minimum viable product on a constrained budget, focusing on core payment functionality. Native Android only. Basic features. Enough to validate that users would adopt the platform.
They did.
Years two and three required rebuilding for scale. The initial success demanded iOS support, which meant cross-platform development. We evaluated our options and made a choice that would define the next several years. The collaboration features—text, audio, video communication—required deep integration work. We built, tested, discovered limitations, and rebuilt again. The Operations Console took shape during this period, replacing manual processes with systematic workflows.
This is where most project-based engagements would end. MVP delivered. Handoff complete. Move to the next client.
We stayed. Because the platform wasn’t finished. It was just starting.
Years four and five transformed the platform into what it is today. Self-service marketplace capabilities let any entity create commerce—B2B or B2C. Wallet infrastructure enabled QR code transactions similar to India’s UPI system. The most innovative addition: peer-to-peer cash exchange, essentially turning users into mobile ATMs for their communities.
That last feature deserves attention. Traditional banks can’t economically serve every location. But platform users are everywhere. By enabling peer-to-peer cash exchange—one user with digital currency, another with physical cash, meeting to exchange—the platform created banking access where banks don’t exist.
This feature wasn’t in the original requirements. It emerged from understanding the problem deeply enough to see solutions the client hadn’t imagined.
The Platform Today
KeyZane is live. You can download it from the App Store or Google Play and see for yourself.
The platform delivers the founding vision: Social Market Network, day-to-day lifestyle services, payments, remittances, commerce, collaboration tools, and micro-financial products – all in a single Super App. It operates in Central and West Africa, serving diaspora communities globally. The infrastructure is proven at scale, expanding market by market.
What started as an economic inclusion vision became a comprehensive ecosystem: individuals connecting with businesses, businesses connecting with governments, communities forming around shared interests and commerce.
The entity-context architecture we built—powered by KeyZane’s patented ORP Technology and seemingly over-engineered in year one—now enables use cases we couldn’t have anticipated: municipal governments offering digital services to constituents, community groups organizing commerce, financial products that let any user become an investor or access micro-credit.
None of this was specified in the original engagement. All of it was possible because we asked “why” instead of accepting requirements at face value.
My Role: From Architect to CTO
I should be direct about my involvement. I didn’t oversee this project from a distance. I started as solution architect, became the lead developer, designed the user experience, built the engineering team, and now serve as KeyZane’s CTO.
This wasn’t the plan. It’s what the engagement required.
Platform engineering at this level demands technical leadership that stays with the product. Not advisors who parachute in for architecture reviews. Not consultants who hand off after design documents. Leaders who write code, debug production issues, and make the daily decisions that compound into platform quality over years.
KeyZane’s founder, Dr. Severin Kezeu, asked me to take the CTO role because that’s what I was already doing—providing the technical leadership the platform needed through every phase of its evolution.
This is what Bluemind means by “product engineering as a service.” Not staff augmentation with a better label. Actual technical leadership embedded in client products, building teams, establishing engineering culture, and staying until the platform can run independently.
The team we’ve built can now do what I did for KeyZane. That’s the model: land, lead, build the team, transfer the capability, repeat.
What We Learned
Five years building a single platform teaches lessons that shorter engagements can’t.
Architectural decisions compound. The choices you make in year one either constrain you or enable you in year five. We’ve seen both. The flexibility we built into entity relationships paid dividends for years. The shortcuts we took in other areas required eventual rebuilding. Platform engineering requires thinking about decisions as investments with multi-year returns.
“Why” reveals requirements that “what” obscures. Clients know what they want. They don’t always know why they want it. Asking why—repeatedly, respectfully, persistently—uncovers the actual problem being solved. That understanding lets you build solutions that transcend the original ask.
Operations infrastructure is platform infrastructure. The back-office isn’t an afterthought. Purpose-built operational tools—designed alongside the product, not bolted on later—determine whether a platform can actually run at scale. Build the Operations Console with the same care as the mobile app.
Constraints are features. Building for Africa’s infrastructure environment forced engineering discipline that made the platform better everywhere. Don’t avoid constraints. Let them shape your architecture.
Creation is different from execution. A cook follows recipes. A chef creates dishes from available ingredients. Platform engineering is creation—taking a vision, a set of constraints, and a willingness to discover requirements through building—and producing something that didn’t exist before. This requires different skills, different relationships, and different timelines than project execution.
Multi-year commitment isn’t a cost. It’s a requirement. Platforms that matter can’t be built in six-month sprints. They require sustained investment, accumulated knowledge, and teams that stay with the product long enough to understand its evolution. When we tell clients we partner on multi-year engagements, we’re not describing a business model. We’re describing what platform engineering actually requires.
Why This Matters For You
If you’re a CTO or product leader evaluating engineering partners, the KeyZane story offers a test.
Ask your prospective partners: What’s the longest you’ve worked on a single platform? What did you learn in year three that you didn’t know in year one? How do you build for requirements that don’t exist yet?
If the answers are vague—if the longest engagement is measured in months, if learning is described in terms of technologies rather than product evolution, if flexibility is a bullet point rather than an architectural philosophy—you’re talking to a project shop, not a platform engineering partner.
We’ve spent 19 years building platforms. Fourteen years on Ark, our MRO master data governance platform. Five years on KeyZane. Both taught us that platform engineering is a discipline distinct from software development—requiring different questions, different commitments, and different relationships between engineering partners and the products they build.
The question we ask every prospective client is the same one we asked throughout the KeyZane engagement: Why?
Why this product? Why now? Why does it matter?
The answers shape everything that follows.
See For Yourself
KeyZane is available on iOS and Android. Download it.
Explore the platform. See what five years of committed platform engineering produces.
And if you’re building something that requires that level of commitment—a platform, not a project—we should talk.
