
Web Design
Why Most Nigerian Fintech Apps Are Broken (A QA Engineer's Perspective)
Why Most Nigerian Fintech Apps Are Broken (A QA Engineer's Perspective)
I've been testing software since June 2022, and I need to tell you something that's been bothering me: most Nigerian fintech apps are fundamentally broken. Not in the catastrophic "your money disappeared" way (though that happens too), but in the thousand tiny cuts that make you want to throw your phone across the room.
Since I started QA, I've primarily tested foreign apps and software through international QA agencies, with only a few Nigerian contract gigs sprinkled in. This means I've seen what 'good' looks like. I've tested apps built by well-funded Silicon Valley startups with dedicated QA teams. I've worked on European fintech products with strict accessibility requirements. I've seen what happens when QA is actually prioritized from day one.
So when I test Nigerian apps, I'm not comparing them to some theoretical ideals, I'm comparing them to real products I've personally tested that somehow manage to not have these basic issues. The gap isn't about talent. Nigerian developers are just as skilled. The gap is about process, investment, and priorities.
As a QA Engineer and Co-Founder at Collectiva, I've seen both sides of this story. And as someone who's tested countless apps across multiple continents, I can tell you exactly why your banking app keeps glitching, why that payment won't go through, and why you're stuck refreshing the same screen for the fifth time today.
The Problem Nobody Wants to Talk About
Here's what happens when I download a new Nigerian fintech app for the first time: I find bugs within ten minutes. Not edge cases. Not obscure scenarios that only happen when Mercury is in retrograde. Basic functionality issues that affect everyday users.
The button that doesn't respond on the first tap. The form that doesn't accept your BVN even though you've typed it correctly. The transaction that succeeds but shows an error message. The screen reader that announces "button button button" instead of actual information, leaving visually impaired users completely lost.
These aren't just annoyances. When you're dealing with people's money, every bug is a trust violation.
What I See That You Don't
After nearly three years of testing software, I've developed what I call "QA vision" the ability to spot problems that most users just accept as "that's how apps work." Let me walk you through what a typical Nigerian fintech app looks like through my eyes:
The Accessibility Nightmare
Nigeria has millions of people with visual, motor, and cognitive disabilities. Our fintech apps? They're built like these people don't exist.
Text is too small. Colour contrast is terrible (try reading grey text on a white background in Lagos sunlight). Buttons are too close together. Screen readers can't navigate properly. There's no keyboard navigation for people who can't use touchscreens effectively.
I've tested apps where visually impaired users literally cannot complete a transaction because the screen reader just reads "unlabelled button" fifteen times in a row. We're not talking about nice-to-have features. We're talking about excluding entire segments of the population from financial services.
The "Minor" Bugs That Aren't Minor
Then there are the bugs everyone experiences but has learned to work around. You know the drill:
The payment button that requires three taps instead of one
The form that clears all your data if you accidentally hit the back button
The verification code that arrives 10 minutes late
The transaction history that shows wrong dates
The app that logs you out randomly and makes you go through the whole authentication dance again
These feel "minor" to developers because the app technically still works. But to users? Each one is a moment where they question whether they can trust this app with their money.
I've watched real users spend 20 minutes trying to complete a 2-minute transaction because they kept hitting these "minor" issues. Some gave up entirely. That's not a minor bug, that's a failed business transaction.
The Japa Factor: How Brain Drain Broke Nigerian Fintech
But here's where it gets interesting. Many of these issues aren't because Nigerian developers don't know how to code. The problem is structural, and it has a name: the "Japa" exodus.
Since 2020, Nigerian tech talent has been leaving in waves. Better pay abroad. Better opportunities. Better quality of life. You can't blame them but the consequences for Nigerian fintech have been devastating.
Here's what I've observed happen at multiple companies:
A fintech launches with a solid team. They build version 1 of the app. It works pretty well with a few minor bugs, but they know where all the bodies are buried in the codebase. Then, one by one, the developers leave for opportunities in Canada, the UK, the US, or remote roles paying in dollars.
The company has a choice: pay the remaining developers enough to retain them and maintain the existing codebase, or start fresh with cheaper, newer developers.
Most choose option two.
The Rebuild Cycle: Starting From Scratch Every Two Years
I've seen this pattern repeat itself across the industry: Company dumps the entire previous version. Hires a new development team. Builds version 2 from scratch [a lot of times with code from version 1]. The new team gets the general functionality right because they're following the same specifications. But they miss the nuance.
The previous developers knew that the transaction flow needed a specific 2-second delay or it would fail. The new team doesn't know this, so they remove the delay to make things "faster." Now transactions fail intermittently.
The old team knew that a particular input field needed custom validation because the BVN verification API sometimes returns data in an unexpected format. The new team uses standard validation. Now 5% of users can't verify their identity.
The previous developers had fixed fifty small bugs that weren't documented anywhere except in the code itself. The new team reintroduces forty-seven of them.
The Fear of Fixing
And here's the worst part: when users report these bugs, the new development team is often too scared to fix them.
Why? Because they didn't build the original system. They don't fully understand how everything connects. They're worried that fixing one small bug will cascade into breaking five other things they don't even know exist.
So the bugs persist. Users learn workarounds. The company posts on social media about "innovation" and "disruption" while their app can't handle a simple password reset without glitching.
The Missing Link: QA Engineers
You know what would catch most of these issues? A QA Engineer involved from day one.
But here's the reality: most Nigerian fintech teams don't include QA Engineers in their early development stages. Quality Assurance is seen as a luxury, something you add later when you have budget. Or worse, it's seen as something developers can do themselves "when they have time."
This is like building a house and only checking if the foundation is solid after you've finished the roof.
When QA Engineers are brought in late (if at all), we're trying to test a finished product rather than catching issues during development. It's the difference between preventing a problem and trying to patch it after users have already suffered through it.
I've joined product development sessions where I'm the first person to ask: "But what happens if the user's internet drops during this transaction?" Or "Have we tested this with screen readers?" Or "What if someone enters their phone number with spaces?"
These aren't genius-level questions. They're basic QA thinking. But if there's no QA person in the room, nobody asks them.
What Good QA Actually Looks Like
At Collectiva, I'd love to say we built QA into the process from the beginning. However, that didn't exactly happen because, as a startup, we've had to pivot fast and make almost instant changes to resolve pressing inconveniences for users in the moment. However, before major releases, we try to do the following:
Functional testing (does it work?)
Accessibility testing (can everyone use it?)
Edge case testing (what happens when things go wrong?)
Integration testing (does it play well with other features?)
User acceptance testing (do real users actually understand this?)
When we find bugs (and we almost always do), we do our best to fix them before shipping. Not because we're perfectionists, but because we know every bug is a moment where users might lose trust in us.
Is this slower? Yes. Does it cost more upfront? Yes. But you know what's more expensive? Losing users because your app doesn't work. Dealing with transaction failures. Rebuilding your entire platform every two years because the codebase became unmaintainable.
The Real Cost of Broken Apps
When your fintech app is broken, you're not just losing users, you're reinforcing the exact lack of trust that keeps many Nigerians away from digital financial services in the first place.
Every time someone tries to send money and the transaction fails, they remember why they preferred cash. Every time someone can't access their account because the app is glitching, they remember why they kept their money under the mattress. Every time someone with a disability can't use your app, you're telling them they don't deserve financial inclusion.
We talk a lot about financial inclusion in Nigerian fintech. But inclusion means building products that actually work for everyone, not just able-bodied users with perfect internet connections and infinite patience for bugs.
What Needs to Change
If you're building or investing in Nigerian fintech, here's what needs to happen:
1. Pay your developers properly. Stop the japa-rebuild-japa cycle. Retention is cheaper than constant rebuilding. If you can't afford to pay competitive rates, you can't afford to build a fintech company.
2. Hire QA Engineers early. Not after launch. Not "when we have budget." From day one. Quality isn't a luxury, it's the foundation of trust.
3. Prioritize accessibility. Nigeria has millions of potential users with disabilities. Build for them from the start, not as an afterthought.
4. Document everything. When developers leave, their knowledge shouldn't leave with them. Proper documentation means the next team doesn't have to rediscover every edge case through user complaints [To be honest, this is harder than it should be].
5. Test with real users in real conditions. Your app might work perfectly on your iPhone 14 Pro with 5G in Ikoyi. How does it work on a 3-year-old Android phone with spotty 3G in Ilorin?
Why I'm Writing This
I'm not writing this to trash Nigerian fintech. I'm writing this because I believe we can do better. I've seen what's possible when companies actually invest in quality. I've seen the difference good QA makes. I've seen users' faces light up when an app actually works the way they expect it to.
As a QA Engineer, my job is to break things before users do. To ask uncomfortable questions. To be the voice of the user who doesn't have the technical vocabulary to explain why something feels wrong.
At Collectiva, we're betting that quality matters. That users will choose the app that works consistently over the app with the flashiest marketing. That doing things properly from the start is better than rebuilding every two years.
We're not perfect. We have bugs too (if you find one, please tell me seriously). But we're committed to fixing them, not ignoring them. To building for everyone, not just some people. To earning trust through reliability, not just promising it through ads.
The Bottom Line
Most Nigerian fintech apps are broken because we've accepted broken as normal. Because we've prioritized speed over quality. Because we've treated QA as optional. Because we've chosen cheap and fast over sustainable and reliable.
But it doesn't have to be this way.
If you're a user, demand better. When an app doesn't work, don't blame yourself, report the bug. Your feedback is the only way companies know what needs fixing.
If you're building fintech, invest in quality from day one. Hire QA Engineers. Pay your developers. Build for accessibility. Document your code. Test thoroughly. Fix bugs before they reach users.
And if you're an investor, ask the hard questions: Who's responsible for quality? What's the testing process? How are you retaining technical talent? What's your accessibility strategy?
The future of Nigerian fintech isn't about who can raise the most funding or launch the fastest. It's about who can build products that actually work, consistently, for everyone.
And from where I'm sitting, there's still alot more work to be done.


