We replaced a white-label vendor app for 118,000 members and took the store rating from 2.6 to 4.6 in a quarter.

A US Credit Union's Mobile Banking Rebuild

The Objective

A four-state credit union served 118,000 members through a white-label app it did not own and could not change, one built and maintained by a vendor whose release calendar ran on its own schedule rather than the credit union’s. Freezing a lost card took four taps buried behind three menus, so most members gave up and phoned the branch instead, the app store rating sat at 2.6, and every fix, however small, waited in a vendor ticket queue for months. We built a Flutter app on iOS and Android directly against their core banking API, with one-tap card controls, biometric login, staged rollout through feature flags, and a two-week release train replacing an eleven-week vendor cycle. The roadmap, and the ability to act on it, came back in-house.

Service Tags

Flutter Development FinTech Development System Integration Accessibility

Industry Tags

FinTech Banking

Tech Stack

Flutter NET Azure PostgreSQL Plaid Twilio

The Impact

2.6 → 4.6
Rating Recovery
App store rating change across the first 90 days
4 → 1
Faster Card Freeze
Taps required to freeze a card
34%
Fewer Card Calls
eduction in card-related contact centre calls
100%
Accessible Screens
Screens meeting WCAG 2.2 AA at launch
The Client

Member-Owned Credit Union Operating 21 Branches Across Four States

A member-owned credit union operating 21 branches across four states, competing for deposits against national banks with far larger digital budgets and far larger in-house product teams. They came to us after their third year on a white-label platform supplied by a core banking vendor, a relationship that had given them a working app but no ability to change it without a change order and a wait. What they wanted was not simply a new app but ownership of the roadmap itself, and a partner who understood examiner expectations, release governance and the core banking integration surface well enough to plan around them from day one rather than discover them mid-build.

The Problem

The Most-Used Card Function Required Four Taps to Complete

A member who loses a card wants it frozen in the next ten seconds. On the old app that took four taps, and most members gave up and called the branch, which meant the contact center absorbed a volume of calls the app existed to prevent. Everything else was the same shape: the vendor owned the roadmap, so a change the board approved in March shipped in the autumn if it shipped at all. The store rating was 2.6 and the reviews named specific screens. Members under sixty were opening accounts elsewhere and telling the branch staff it was because of the app, which is the version of churn that shows up in a board pack.

Our Approach

The Regulatory Security Review Was Scheduled Before Development Began

Regulated builds fail on the calendar, not the code. Penetration testing, the examiner walkthrough and the core banking integration review all have queues, and a team that treats them as a closing phase discovers in month seven that launch is in month ten. We booked all three at the start and worked backwards from them.

Card controls went first among the features. It was the highest-volume member action, the loudest source of contact-center cost, and the clearest proof to a skeptical board that the rebuild was worth its budget. Shipping it early gave the project internal air cover for everything that followed.

Biometric login and the middleware layer went in alongside card controls rather than after, because every other feature on the roadmap, transfers, bill pay, mobile deposit, would sit on top of that same authentication and API surface. Building it once, correctly, ahead of the feature list meant later screens were additive rather than each one renegotiating how it talked to the core.

Test automation went in alongside the first screens rather than after them. We knew the two-week release train was the actual deliverable, because a bank that can ship fortnightly has a different relationship with its members than one that ships three times a year, and a fortnightly cadence without an automated regression suite is a fortnightly outage risk. The cadence works because feature flags separate deploying code from releasing a change: most trains carry app-tier work that ships freely, while anything touching regulated behavior is gated and batched into the change-management path the examiner expects.

What We Built

A Unified Mobile Banking Experience

One Flutter App on Two Platforms with a Middleware Layer Over the Core Banking System

Biometric Login
Card Freeze and Unfreeze
Card Controls (Limits and Categories)
Internal and External Transfers
Mobile Cheque Deposit
Bill Pay
Alerts Centre
Feature Flag Console
How It Was Built

Nine-Month Build That Included Six Weeks of Security Review Booked on Day One

Ten people: one PM, one BA, one UX designer, three Flutter engineers, two .NET engineers, one QA automation engineer and one security engineer embedded throughout. Flutter carried both platforms, which mattered more than usual here because every screen had to pass the same accessibility audit twice otherwise. We ran a staged rollout through feature flags, staff first, then 5% of members, then four widening bands, with the old app live throughout. The examiner walkthrough happened against a working build in month six rather than a document in month nine.

Outcome

Card Freezes Complete in One Tap and Releases Ship Every Two Weeks

A member who loses a card freezes it before they finish retracing their steps, and the contact centre no longer takes that call. Card controls, transfers, deposits and alerts sit where members reach for them, and the reviews now name features rather than failures. The credit union’s own product team writes the roadmap and sees it ship on a fortnightly train, with feature flags letting them put a change in front of 5% of members before all of them. Accessibility passes at AA on every screen, evidenced at audit rather than argued after a complaint. The next product, a youth account or a savings goal tool, is a sprint decision now.

Testimonials

"Our last partner treated the security review as something that happened to the project. This team put it on the schedule before they wrote a screen, and that is the single reason we launched when we said we would." —

credit union

Chief Digital Officer

Build Beyond Vendor Limits

If a vendor platform owns your roadmap and your members are reviewing you on it, bringing the app in-house is a bounded project with a known schedule.

Start the conversation