I want to start with the thing I keep having to explain to people who build software in well-resourced environments: the problem is not connectivity.
The connectivity framing is seductive because it's partially true and completely misleading. Yes, there are coverage gaps. Yes, speeds vary. But the more fundamental issue is that most software is built with assumptions that are so baked into the design that developers don't even recognise them as assumptions.
Assumptions like: the user has a credit card. The user has a verified email. The user will tolerate a 200ms API call before the UI responds. The user knows what a "workspace" is in the SaaS sense. The user's phone has at least 2GB of RAM. The user is accustomed to English-language error messages. The user will read the onboarding flow before trying to use the product.
These aren't wild assumptions for a user in San Francisco or Berlin. They're wrong assumptions for a significant portion of users in Lagos, Abuja, Nairobi, or Accra — and they manifest not as edge cases but as the entire mainstream experience.
What building for African markets actually teaches you
When you strip the assumptions, you're left with first principles. What does this feature actually need? What's the minimum viable version that delivers the core value? What happens when this fails — and it will fail? How does this degrade gracefully?
Offline-first architecture is the clearest example. When I built EduCore, designing for offline wasn't a feature flag I added at the end. It was the core design constraint that shaped every data model, every sync strategy, every conflict resolution decision. The result was a more resilient system than I'd have built if connectivity was assumed.
"Designing for the constrained case produces software that works better everywhere. A form that loads fast on 2G is a form that loads fast on 5G too."
The same principle applies to payment flows. When I can't assume a credit card, I have to think harder about trust, about progressive commitment, about what value the user needs to experience before they're willing to pay anything. This makes the product better for every user, not just the ones without credit cards.
The infrastructure constraint as creative pressure
ideyCDN was born entirely from this. The constraint was a shared hosting account — no VPS, no containers, no managed databases. Most developers would have said "you can't build a serious product on shared hosting" and stopped there. I took it as a design problem: what's the best CDN architecture that runs within these limits?
The two-level sharded file storage system, the asset pipeline via cron jobs instead of long-running workers, the NestJS-on-Phusion-Passenger configuration — these solutions came from the constraint. And they're solutions that other developers building in similar infrastructure contexts can now use.
The market size argument
There's a cynical version of this conversation where someone says the African market isn't worth the complexity. I'd push back on the premise. Nigeria alone has 220 million people. The continent has 1.4 billion. The smartphone penetration rate is growing faster than anywhere else. The developers, entrepreneurs, and consumers being underserved by current software are not a niche — they're the next major wave of digital adoption.
But honestly, I don't build for African markets primarily because of market size. I build here because I'm here, because I understand the context, because the problems are real and the solutions matter. The business case follows from that.
What I'd say to developers elsewhere
Try building your next feature as if your user has a 3G connection, 500MB of storage, and will switch apps in the middle of the flow. See what it forces you to simplify. See what you assumed was necessary that turns out not to be. The constraints are a gift, not a penalty.