Every quarter, a new fintech launches in Africa with a beautiful app, a slick pitch deck, and an infrastructure that collapses the moment real users show up. I have seen it happen too many times to count. The pattern is always the same: move fast, ship the MVP, raise money, then discover that the thing you built on top of sand cannot hold the weight of actual demand.
We refused to build ZWAP that way.
Infrastructure Is Not Sexy Until It Breaks
Nobody talks about the database schema that prevented a double spend at 2am. Nobody tweets about the queue system that handled 50,000 concurrent transactions without dropping a single one. But these are the decisions that separate a product people trust from a product people abandon the moment something goes wrong.
When we started building ZWAP, I made a decision that probably slowed us down in the early days: we would invest heavily in the foundational layer before building features on top of it. Payment routing, reconciliation engines, idempotency keys at every write operation, circuit breakers for third party APIs, and a monitoring stack that tells us about problems before users do.
The Real Problems Nobody Prepares You For
Building payments for Africa means dealing with realities that most Silicon Valley architecture patterns were never designed for:
- Payment providers that return success but the money never arrived
- Bank APIs that go down for 6 hours with no status page
- Users on 2G connections trying to complete transactions
- Regulatory requirements that change between Tuesday and Wednesday
- Currency volatility that can wipe out margins in minutes
Each of these requires not just a workaround, but a fundamental architectural decision about how your system handles failure. We built our reconciliation engine to be the source of truth, not the external providers. If a provider says a transaction succeeded but the funds do not appear in our settlement, we catch it. If a provider says it failed but the user was charged, we catch that too.
Why We Chose Our Stack
I get asked about our technology choices a lot. The honest answer is that there is no perfect stack, only the right stack for your specific constraints. We needed something that could handle high throughput, be debuggable by a small team, and not require a cloud bill that would eat our entire runway.
Our core services run on technologies that prioritize predictability over trendiness. We use relational databases because financial data demands strong consistency. We use message queues because payment processing is inherently asynchronous. We use observability tools that let us trace a single transaction across every service it touches.
The goal was never to use the newest tool. The goal was to use tools that we understand deeply enough to fix at 3am when something breaks in production.
What I Tell Every Engineer Who Joins Us
I say the same thing in every onboarding: we are not building a startup. We are building a financial institution. The code you write today could be processing someone rent money next month. The bug you ignore could mean a family cannot feed themselves because their funds are stuck.
That weight changes how you write software. It makes you add the extra validation. It makes you write the test for the edge case. It makes you think about what happens when the network disappears mid transaction.
What Comes Next
We are just getting started. The infrastructure we have built over the past year is the foundation for everything coming next: real time settlement, multi currency wallets, institutional grade APIs, and payment channels that do not exist yet.
The work is not glamorous. Most days it looks like reading logs, optimizing queries, and arguing about retry policies. But this is the work that matters. This is the work that makes everything else possible.
If you are an engineer who cares about building things that work, not just things that demo well, we should talk.
