When I joined the MCB Mobile team in 2019, the app had 80,000 registered users. Almost none of them were active.
That distinction matters. The 80K number looked like a base to build on. In reality, it was a warning sign — a product that people had tried once and walked away from. Understanding why they left, before doing anything else, was the only honest starting point.
What We Inherited
The screenshots from that era tell the story more clearly than any description can.
Single-screen login. Six-icon grid dashboard. No personalisation, no session identity, no reason to return.
Four wallet functions. Three payment categories. Mini-statement as plain text with raw transaction codes.
Login was a single screen: mobile number, PIN, Submit. No security messaging, no personalisation. The dashboard that followed was a six-icon grid — My Wallet, Transfers, Payments & Top-Ups, Contact Us, ATM Locator, Follow Us. That was the product.
The app was structurally tied to debit card ownership. If you held an MCB account but didn't have a debit card, the app wasn't for you. That eligibility wall was invisible in the UI and deeply consequential in the numbers.
Registration required a branch visit. There was no self-service onboarding. A customer had to commit time and travel before they had seen a single screen of the product they were signing up for.
The platform behind the UI had its own problems — architectural constraints, vendor dependencies, compliance gaps, operational fragility. Every layer of the stack had something that needed fixing. The app was the visible symptom. The issues ran much deeper.
"We had a product that did the minimum, ran on infrastructure that made the minimum difficult, and served a registered base that had already decided it wasn't worth their time."
The Problem with Fixing Everything at Once
The temptation with a product in this state is to fix everything simultaneously. Redesign the UI. Rebuild the backend. Launch new features. Show momentum.
We resisted that — not because the problems weren't real, but because a product with 80,000 inactive users doesn't have a feature problem first. It has a trust problem. Users had registered, tried it, and stopped. Before we could grow, we had to understand exactly where they were leaving and why.
The answer was: everywhere. Platform reliability was inconsistent. Onboarding was branch-dependent. The app was tied to debit card ownership. Fee collection was manual, creating renewal friction and revenue leakage. And the product gave users almost no reason to open it more than once a week. Every one of those was a real problem — but they weren't equal problems. We had to sequence.
Upgrade to the Future: The Inflection Point
The project we called "Upgrade to the Future" was the most complex multi-workstream delivery I've managed in my career. It ran across four major capability areas simultaneously — and each one was load-bearing.
Decoupled registration from mandatory card linkage — expanding the addressable base to every MCB account holder, not just those with a debit card. Required reworking authentication logic, account linkage, and significant backend flows.
Before this, a customer with more than one MCB account had to choose one at registration. The others were invisible. Real-world problem for business owners and families. The engineering underneath — session management, switching logic, data architecture — was not simple.
The unlock. Removing the branch visit requirement changed the economics of acquisition entirely. A customer could download, register, and onboard without leaving their house. This opened the top of the funnel.
In-app digital statement delivery. First time the app gave users something they'd previously had to call a branch or wait for by mail to receive. A retention driver as much as a feature.
None of these shipped in isolation. They were designed together, sequenced carefully, tested against each other, and delivered as a coherent upgrade — not a patchwork of features dropped into an old product.
What the Upgraded App Looked Like
The contrast between the two versions is best understood by looking at both.
Fraud awareness built into the login flow. Personalised dashboard with user name and last login timestamp.
Navigation drawer with Beneficiary Management — a feature that only makes sense for habitual users. Seven payment categories vs three.
The upgraded app opened with something the original never had: a BE AWARE, STAY SAFE splash screen — MCB's fraud awareness initiative built directly into the entry point. Before a user even reached login, they saw a clear message: never share your credentials, PIN, OTP, or card details over any channel. This wasn't decorative. It was a deliberate decision to use the highest-traffic moment in the app — the login flow — to build security awareness at scale.
Post-login, the difference was stark. The old six-icon grid was gone. In its place: a personalised dashboard greeting the user by name, displaying their last login timestamp, surfacing their accounts directly.
The navigation drawer told the story of expanded capability. Beneficiary Management is worth noting specifically — it only makes sense as a feature if you expect users to make repeat transfers. Its presence signals that the product was now designed for habitual use, not occasional transactions.
The Payments screen expanded from three categories to seven: Credit Cards, Mobile Topups, Mobile Bills Postpaid, Utility Bill Payment, Donation Partners, Government Payments, Educational Institute Fee. Each one a reason to open the app that hadn't existed before.
"This was a completely different product wearing the same name."
What Else Had to Change
Branch and Contact Centre Onboarding. Digital self-service was the goal — but not every customer was ready to register themselves. We built a one-window system that let branch staff and contact centre agents complete registrations on behalf of customers. Every branch interaction became a potential activation point for the app.
Real-Time Fee Deduction. Annual service fees were handled manually — inconsistent collection, operational overhead, and P&L leakage every renewal cycle. Replacing that with automated real-time deduction closed a gap that was quietly costing money and creating friction at exactly the moment customers needed a frictionless experience.
Platform Management. The FUNDAMO platform powered MCB Mobile at scale, reaching 2M+ users. Managing it — vendor relationship, core banking integration, feature releases, transition planning — ran as a continuous parallel stream throughout all the product work.
The Team. By the time the platform was performing and the product was growing, we were running a cross-functional team of 20+ people — developers, business analysts, QA engineers, and operations. Building that team and keeping it aligned through years of concurrent projects was its own sustained effort.
The Honest Part
Growth of this kind doesn't happen cleanly. There were failures.
The most instructive one came immediately after launching digital onboarding. The flow was technically sound — every step worked, every test case passed. But we had underestimated how much guidance first-time users needed at the point of self-service registration. Drop-off in the onboarding funnel was higher than it should have been in the early weeks.
"Functional is not the same as usable. Usable is not the same as adopted. A product can pass every test case and still lose users at the moment that matters most."
We iterated — simplifying steps, adding contextual guidance, reducing decisions before completion. The numbers moved. But the lesson stayed.
There were other moments. Vendor escalations that took longer than they should have. Compliance requirements that arrived mid-delivery and forced scope changes. Platform incidents during rollout periods. These are the realities of building in a regulated, multi-vendor environment on infrastructure being upgraded in motion. None of them stopped the trajectory — but they slowed it, and they were expensive in time and team energy.
Where It Ended Up
The growth wasn't a marketing outcome. There was no viral moment, no campaign that drove a spike. It was the compounding result of removing barriers — to registration, to onboarding, to daily use — and building a product that gave customers a genuine reason to come back.
The 80,000 inactive users at the start were not a marketing failure. They were a signal from the product. The app hadn't earned their time. Once it did, the number moved.
What This Means for You
If you're building or scaling a mobile banking product, the questions worth asking aren't "what features should we add." They're structural:
Questions worth asking
- Are there eligibility walls in your registration flow that you've stopped noticing because they've always been there?
- Is your onboarding branch-dependent by design, or by default — and do you know the difference?
- Where are users leaving, and at what step? Do you actually know, or are you assuming?
- Does your platform support the product you're trying to build, or is it constraining it?
- Is your product designed for habitual use, or occasional transactions? Your navigation architecture will tell you which one it actually is.
The distance between 80,000 inactive registrations and 600,000+ active users was not a feature list. It was a set of structural decisions, made in sequence, that removed every reason a customer had to not use the product.