Three Apps, One Platform, Four Million Ringgit a Month - Iqram Ahmed - UX/UI Expert, Designer, Developer & Team Leader
← All Case Studies
Fintech · Mobile App 2016 — ongoing

Three Apps, One Platform, Four Million Ringgit a Month

A user told us he needed three phones to use our service properly. He wasn't wrong.

Type Fintech · Mobile App
Year 2016 — ongoing
Role Lead Product Designer · Frontend Team Lead
Platform Hybrid mobile application · Design system
Read 2 min
Project visual

The platform I'd originally built had grown into three separate apps — one for users sending money and paying bills, one for agents processing transactions at physical locations, one for merchants managing business payments. Each had its own interface logic, its own navigation patterns, its own design language. Migrant workers from Bangladesh, Indonesia, and across Southeast Asia were switching between all three to complete what should have been a single session. Agents needed training on each app separately. Support was drowning in questions about which app to use for which task. Meanwhile, every new feature had to be built three times, and every bug fixed three times. The platform was generating real revenue — RM 4 million a month — but the fragmentation was making it harder to grow and increasingly expensive to maintain.

Because I'd built the original, I knew exactly where the architecture had gone wrong. The three-app structure wasn't a bad decision at the time — it was the fastest way to ship three distinct user types. But what made sense at launch had become the platform's biggest liability. The revamp wasn't about visual improvement. It was about collapsing three separate mental models into one without losing the distinctions that made each user type's experience work. I approached it as a product consolidation problem first, a design problem second — mapping how users, agents, and merchants actually moved through their tasks before touching a single screen.

We built context-aware navigation that changes based on who's logged in. Users see transfers, top-ups, and bill payments. Agents see transaction processing and customer tools. Merchants get analytics and payment management. Same app, different experiences. The alternative — separate apps — had already proven unworkable. The risk here was complexity inside one codebase, which we managed through the design system rather than by simplifying the product.

I led the frontend implementation alongside the design work rather than handing off to another team. For a project where design decisions and technical constraints were tightly coupled — performance on older devices, multilingual rendering, component reuse across three user flows — that overlap mattered. It meant fewer translation errors between design intent and built output, and a component library that was designed and built by the same thinking.

We designed for the hardest user first. Construction workers using the app outdoors, on older phones, wearing gloves, on slow connections. Large touch targets, high contrast ratios, progressive loading so core functions work before everything else has finished downloading. Designing for that constraint produced an interface that worked better for every user type, not just the most demanding one.

We maintained the RM 4 million monthly transaction volume through the transition rather than accepting a dip as inevitable. This shaped every sequencing decision in the revamp — what to migrate first, what to keep stable, when to cut over. Revenue continuity was treated as a design constraint, not just a business hope.

60%

reduction in time to ship new features after consolidation to a single codebase

Three codebases became one. Feature development that previously required building, testing, and maintaining three separate implementations now happens once. The 60% reduction in development time is the direct result of that consolidation — not process improvement, structural change. The RM 4 million monthly transaction volume was maintained through the migration without a meaningful dip. Users are completing more transactions per session, agents are processing faster with a unified interface, and support volume around 'which app do I use' has dropped significantly. The platform is still being actively developed — the foundation now scales in a way the three-app structure never could.

I built the original three-app structure, so I also built the problem this revamp is solving. The split made sense when we needed to ship fast for three distinct user types. I'd make a different call now — a single platform with role-based experiences from the start costs more upfront and saves significantly more over time. That's a lesson I had to earn the slow way.

Get in touch

If you are working on something
that needs this kind of thinking,
I would like to hear about it.