Banks are modernising their infrastructure to adapt to markets, launch products faster and configure services more quickly. Mobile banking reflects this shift, with major features that once took more than a year now reaching first production release within weeks. But faster development does not always mean faster deployment, as testing, security, data readiness, partner coordination, certification and customer adoption can still slow launches.

Average industry mobile banking development timelines for major features and updates have fallen from nine to 18 months before 2015 to six to nine months from 2015, and three to six months since 2020. Digital banks often move faster. However, a bank may be able to deploy weekly while a major new feature still takes months to move from incubation to commercial launch.

Those timelines are likely to shorten further as artificial intelligence (AI)-assisted development reduces the time needed for requirements analysis, coding, configuration, testing and troubleshooting. Frontier AI companies show how quickly development can move, with teams of fewer than 10 people completing work in days or weeks, although they are not directly comparable with regulated banks. In banking, individual development tasks may increasingly take days, but commercial launches still depend on integration, security, data validation, approvals, partner readiness and customer adoption.

Banks will gain a competitive advantage not only from faster coding, but also from better architecture, controls and decision-making that allow smaller teams to deliver safe, repeatable releases.

Team sizes for product development and deployment have also fallen, from 15 to 20 people to around 10 to 15. Banks often describe these cross-functional teams as small, empowered units that manage services end to end and develop new products as experimental initiatives. The shorter development cycles are part of a broader shift in banking infrastructure modernisation over the past decade, with banks taking greater ownership of their infrastructure rather than relying on outsourcing. Banks have found that outsourcing critical functions can mean higher costs and slower responses to market changes. The goal is to innovate faster, build stronger in-house capabilities and reduce costs.

Today, cross-functional teams can manage more of the process from requirements to production as banks adopt cloud-based infrastructure, microservices, core banking decomposition, configurable product engines, continuous integration and automated testing. The main benefit is fewer hand-offs, including with third-party providers, and less rework rather than simply faster coding. Some banks in our assessment programmes link twice-monthly mobile banking releases to continuous delivery and private-cloud infrastructure, while others more than halve development and testing time after adopting modular, configurable architectures.

Configuration and reuse speed up delivery

Modernisation changes how banks develop mobile features and products. These are no longer mainly software-development projects. Instead, work shifts towards setting parameters, preparing data, validating controls and deciding how much customisation is needed. The same applies to partner integration: reusable components and parameterised connections reduce one mobile integration cycle from more than 10 weeks to about six, a 40% improvement.

Modular, parameter-driven services cut complex product delivery from at least six months to three. Overall, modern architecture makes changes smaller, while better delivery processes make them safer and faster to release.

Small teams work when dependencies are reduced

Team structure often follows architecture. In one case, the old product process involved vendor discussions, requirements, implementation, hand back and bank testing, so a smaller internal team alone would not have removed these delays. The cycle shortened only after modular, parameter-driven services allowed the delivery team to own and change more of the work.

Cross-functional squads work in two- to three-week cycles, bringing business and technology decisions closer to the customer journey. Small teams fast-track work only when they also control the relevant services and decisions.

Deployment speed depends on infrastructure, but release frequency depends on customers

Banks distinguish between development cycles and deployment frequency. They may release invisible fixes frequently, but bundle changes that require customer explanation and adoption. One bank can deploy mobile features weekly, but management chooses weekly, fortnightly, three-week or monthly customer-facing releases based on how much change customers can absorb.

Complaints can rise when customers receive too much new information at once or when the journey changes too frequently. Some banks also work in two- to three-week squad cycles but deploy monthly to avoid overwhelming customers.

Quality and controls still take time

Faster development cycles do not eliminate control work; they shift where the time is spent. In some cases, cutting the mobile development cycle from 60 to 30 days initially weakened application stability as features were developed in parallel. The bank responds by expanding its beta group from about 50 to more than 300 users and strengthening feedback before a wider release.

In some cases, development takes weeks while external technology certification takes more than a year. AI can also reduce requirements work to days, but its outputs are only 70–80% accurate and still require human review, with data quality proving the biggest challenge.

The common lesson is that faster development increases the need for automated testing, risk-based approvals, production monitoring, controlled experiments and beta testing. Without these controls, banks either release instability faster or recreate long delays at the approval stage.

Development cycle time is only part of the picture

Average cycle time can hide where delays occur, as work may spend months moving between requirements and testing. A standard product can be configured in two to four days, but bank preparation and customisation can take longer. Timelines also vary based on dependencies and risk: a mobile-layer update may take weeks, while a partner-dependent feature or one requiring external certification may take months.

Deployment frequency is another measure. A bank may be able to deploy weekly but choose a monthly customer-facing release cycle. Speed should therefore be measured alongside stability, adoption and rework. The key measure is how quickly a bank can turn a validated need into a stable feature that customers understand and use.

What faster development can and cannot achieve

Mobile banking feature development has shifted from long, one-off programmes to smaller, configurable and more frequent releases. Our analysis shows that delivery times for major mobile banking features have fallen from many months under earlier waterfall models to weeks or a few months today. The pace varies depending on where the process starts and how many dependencies a feature has.

Requirements can now move from weeks to days, standard configuration can take just a few days and deployment can happen weekly. However, partner integration, certification, data validation, stability and customer adoption often follow different timelines. The strongest operating model is not simply the one that releases most often, but the one that identifies and shortens the main source of delay without increasing risk downstream.