A large retail bank has recently asked us to review the performance of a mobile app that had become central to its digital strategy. On paper, the scope looked narrow, but in practice, it exposed a much larger delivery problem.
The app was carrying bigger product expectations than the system behind it could comfortably support. Release confidence was uneven. Cross-team dependencies were heavy. Parts of the architecture were moving toward a mini-app model, but the foundations needed to run that model well were still missing.
That pattern can be spotted across the banking industry. Customers judge the bank through the product in their hands, and that standard has moved fast in recent years. McKinsey found that 71 percent of consumers expect personalized interactions, and 76 percent get frustrated when they do not get them. In banking, that expectation lands on a product that has to feel clear, fast, safe, and current every day, not only after a redesign or a major release.
Fintechs have pushed that shift harder. Revolut now serves 70 million customers globally, while players like Monzo and Nubank have trained users to expect faster product iteration, cleaner interfaces, and less friction in everyday banking. Traditional banks still have trust, scale, and market share. Those advantages no longer guarantee that the app feels competitive.
The problem is usually structural before it is cosmetic
It is easy to blame stalled modernization on legacy code and stop there. And legacy systems do matter, but that explanation alone is too shallow. The harder problem is that the mobile product has to move through an operating model that was never built for speed.
In large banks, a customer-facing app often sits on top of older backend systems, centralized security review, shared release dependencies, architecture approvals, and multiple internal groups with overlapping authority. Product, engineering, architecture, security, and platform-adjacent functions all have a say. Each control may be reasonable on its own, but together, they can make even a straightforward product work slower than it should.
That is what surfaced in our client’s case. The mobile team was not missing ambition or competence. The thing was, delivery was fragmented across too many seams. Different teams were seeing different versions of the same issue: testing gaps in one place, release friction in another, observability issues somewhere else, and architecture complexity spread across the rest. No one was looking at the system as a delivery system.
That pattern lines up with broader modernization research, which shows that modernization is shaped by organizational, operational, and technological factors together. Banks often start with a product ambition to expand the app faster, add more services, or support a super-app direction. The blocker shows up later, when the delivery model, architecture, and engineering foundations are not ready to support that shift.
Banks usually need to close three gaps at once
The banks that make progress are usually closing three gaps at the same time.
Feature competition
The first gap is product breadth. Customers expect banking apps to do more than show balances and enable transfers. Many banks are now turning the mobile app into a broader service layer that brings together payments, card controls, savings, lending, insurance, loyalty features, partner offers, and support in one place.
At the same time, expectations around personalization are rising. Customers are getting used to apps that adapt to behavior, surface more relevant offers, and make the experience feel more responsive to individual needs. Once that becomes the market baseline, feature gaps stop looking temporary.
That does not mean every bank should copy every fintech feature. It does, however, mean product gaps are more visible and more strategic than they used to be.
Fintech-grade customer experience
The second gap is experience quality. A bank can have the right roadmap and still feel behind if the app is slow, hard to navigate, inconsistent, or awkward at key moments. Customers do not separate trust in the institution from trust in the product. If the app feels dated, the bank starts to feel dated with it.
High-velocity delivery
The third gap usually decides whether modernization goes anywhere: delivery velocity.
Most banks know what they want to build. The harder part is releasing features with enough consistency, enough confidence, and enough room to keep improving. In the banking programs we have seen, the bottleneck often sits in the delivery foundations:
- CI/CD that is partial, slow, or uneven across teams,
- testing strategy that exists in fragments rather than as a real operating discipline,
- release management that surfaces problems late,
- weak observability into user-facing issues,
- onboarding and documentation gaps that increase dependency on a small number of experienced people,
- branching, ownership, and repository models that add friction instead of removing it.
That is the difference between wanting a modern app and being able to ship one.
Architecture only works when the delivery system can support it
Banks often use architecture as the visible sign that modernization is happening. Sometimes that means modular mobile architecture. Sometimes it means mini-apps inside a larger banking app, or a broader super app direction that groups multiple services behind one customer surface.
In the right context, those approaches can make room for parallel delivery, clearer team boundaries, and broader product expansion. They can also slow teams down when the organization is not ready to run them.
That is what we saw in our client’s case. The mini-app direction made sense because the product was expanding and more teams needed to contribute to one app surface. But the strain did not show up in architecture alone. It showed up in repository and dependency complexity, team boundaries that were not yet clean enough for independent ownership, release coordination that relied too heavily on manual synchronization, testing that was uneven across teams, and observability gaps that made issues harder to catch and trace.
Once those problems pile up, the architecture starts adding coordination cost faster than it adds delivery speed.
That is also consistent with research on developer productivity and delivery environments: long feedback loops and high cognitive load reduce output in practical ways. Slow builds, slow testing, heavy reviews, unclear ownership, and repeated interruptions make software harder to ship. Add an advanced modular model on top of that without the right foundations, and the burden only grows.
Mini-apps and super apps are not the problem. Treating architecture as if it can make up for weak delivery foundations is.
What banks actually need is a shared delivery foundation
The most useful modernization work usually happens below the feature layer.
Banks need a delivery foundation that makes teams easier to operate at scale. In practice, that often means a platform team or platform function responsible for shared standards, release foundations, testing, observability, and cross-team enablement. Its job is to remove repeated friction that slows every team down: inconsistent quality gates, fragile release coordination, unclear ownership boundaries, and too much local problem-solving around the same delivery issues.
In a setup like this, product teams can stay focused on building customer-facing features, while the platform function makes the system easier to ship through. That includes improving CI/CD, setting clearer engineering standards, making issues easier to trace, reducing dependency overhead, and giving teams a more reliable path from development to release.
That job usually includes:
- shared CI/CD and release paths teams can rely on,
- testing expectations and quality gates that are consistent across teams,
- better observability so teams can spot user-facing issues sooner,
- clearer boundaries between modules, libraries, shells, and shared services,
- onboarding and documentation that do not depend on tribal knowledge,
- architecture simplification where the current model costs more than it returns.
This is implementation work, not just diagnosis.
Banks do not need another article telling them to "be more agile." They need a credible path from delivery friction to delivery improvement. In regulated environments, that path still has to work with security review, governance, and architecture controls. Speed gained by bypassing enterprise constraints does not last. Speed gained by building a cleaner release system inside those constraints does.
A better question is not "how do banks behave more like fintechs?" It is "how do banks make shipping cheaper and more reliable across multiple teams without lowering the bar on control?"
What we learned from doing the work
One of the clearest lessons from this project is that the first visible issue is often the smallest. In this case, the work started with an audit and performance improvement. That was a sensible entry point, and it led to immediate results. That would have been useful on its own, but it was not the main story.
Once we moved from one team’s view to the broader mobile setup, the larger pattern came into focus. Multiple teams were dealing with recurring problems that looked separate on the surface but shared the same roots: architecture overhead, weak cross-team standards, inconsistent release practices, uneven testing, and limited visibility into issues.
That changed the recommendation. The work stopped being only about isolated performance wins and became a modernization problem in the fuller sense. Some improvements were tactical: speed up key parts of the app, document specific issues, give teams clearer guidance. Others were structural: strengthen CI/CD, improve testing and observability, reduce unnecessary complexity, and establish a platform-style function that could support the whole system instead of leaving each team to solve the same class of problems on its own.
That is why the most valuable work often grows beyond the initial ask. It starts with a review, then moves into prioritization, engineering fixes, shared standards, release improvements, and decisions about what needs to be simplified versus strengthened. Banks do not need another abstract explanation of why enterprise delivery is hard. They need a partner that can find the bottlenecks, make the tradeoffs clear, and do the engineering work required to remove them.
Modernization starts paying off when delivery catches up with ambition
To keep up with fintechs moving faster, banks need delivery systems that let product teams ship with more confidence and less friction.
That means treating modernization as more than a rewrite. Migration strategy, mobile architecture, release foundations, testing, observability, and governance need to move together. Otherwise, the roadmap keeps expanding while the release system keeps resisting it.
The banks that handle this well usually stop treating delivery friction as a local team problem. They build shared platform capability around it. When many teams are contributing to one app surface, speed does not come from architecture alone. It comes from shared standards, clearer ownership, stronger release paths, and better visibility into what is breaking.
That is why platform thinking keeps showing up in large digital product organizations. It gives teams more room to move without giving up consistency or control. In banking, that matters even more, because the bar is not just speed. It is speed inside a regulated environment, across multiple teams, without making the product harder to operate every quarter.
If a mobile roadmap is getting blocked by architecture drag, release friction, or weak delivery foundations, that is usually where the review should start.
Learn more about Enterprise
Here's everything we published recently on this topic.
