Cutting Mobile Banking Release Time by 26%

The bank was building its mobile app as a set of Mini Apps covering banking capabilities such as payments, accounts, and cards. Seventeen teams developed and tested these modules in their own repositories; the Shell, the main application, brought them together into one customer-facing app.

A module could work in isolation and still encounter navigation problems or dependency conflicts when integrated with the rest of the app. Shared authentication and native functionality added dependencies across teams. Defects often surfaced during certification, close to a scheduled release. Even a small fix could require publishing another package version, integrating it into the Shell, rebuilding, and repeating validation, taking days to reach a testable build.

Different testing, mocking, and dependency configurations made failures harder to trace, while changes to continuous integration and delivery (CI/CD) and infrastructure required coordination with central teams and existing security and approval processes. Engineers spent time on repeated integration work, and the bank had less certainty about which completed features would make each release. Historically, the time from feature completion to release readiness averaged 19 days.

If one feature failed validation, an entire Mini App update could slip into the next release cycle. That could postpone improvements for customers and add more work to the following release, limiting how quickly the bank could respond to changing customer expectations and digital-first competitors. The bank needed a more predictable path from development to release while meeting the reliability requirements of a staged rollout to a large audience.

We assessed the architecture together with the teams responsible for feature delivery, testing, security, and infrastructure. The bottlenecks crossed organizational boundaries, so our recommendations covered both the codebase and how teams brought it to release.

We migrated development into a shared monorepo, where engineers could validate changes inside the integrated banking app. Teams retained ownership of their feature modules and could develop them in parallel, while the shared setup reduced repeated package publishing and integration steps. The transition exposed issues that isolated environments had hidden; we worked alongside the bank’s engineers to resolve them and adopt the workflow.

We used pnpm workspace linking to make changes available across the app without publishing intermediate packages. We kept a shared record of dependency versions so teams installed the same packages. CODEOWNERS made it clear who owned each feature and should review changes to it.

Adapt delivery tooling with the teams that own it

Working with the bank’s Platform and DevOps teams, we adapted its GitHub Actions pipelines to the monorepo while retaining the existing branching strategy. Feature and release pull requests ran automated lint, type, unit, and integration checks, targeting the shared Shell and affected Mini App. SonarQube analysis focused on changed Mini App files, avoiding duplicate checks. Failed tests stopped the quality workflow before later build stages, giving teams earlier feedback and reducing CI time spent on changes that had already failed validation.

As a result, product engineers gained more direct influence over the tooling they depended on, working across the central teams that controlled delivery infrastructure.

Give the bank a shared view of security risks

We assessed application code and third-party dependencies across the shared repository, giving the bank a consolidated view of security risks across the Shell and Mini Apps. The handover included findings grouped by severity and recommendations for remediation.

Give teams a shared, fast validation layer

We established shared integration-testing standards with React Native Testing Library and configured MSW for network-level API mocking. A reference test with predictable API responses gave feature teams a repeatable pattern for testing their own scenarios.

The delivered baseline contained 18 test suites and 45 automated integration scenarios, executing in approximately 51 seconds. Of those scenarios, 21 came from the supplied critical-flow catalog, 22 were identified during implementation, and two covered the Shell.

The suites gave teams integration feedback in under a minute and shared testing patterns they could extend across Mini Apps and the Shell.

Make application behavior easier to diagnose

We configured Embrace to map JavaScript errors back to Shell and Mini App code, capture unhandled promise rejections, and track navigation. We also enabled trace-context propagation on mobile API calls and verified trace forwarding to Grafana. Centralized dashboards showed startup and navigation performance, including how long screens took to render and become interactive.

Reassure tests established render-time and render-count baselines for selected expensive UI components. We also supplied profiling tooling and an example Maestro flow to collect execution time, CPU usage, memory usage, and frame rate, with guidance for teams to profile additional flows.

Build platform ownership before expanding independent delivery

We reduced repeated integration work and gave the bank’s Platform Team more control over delivery tooling. This freed time for shared tooling, dependency management, security, and upgrades across the app.

We used Re.Pack and Module Federation to extract two Mini Apps into separate workspaces and validate remote loading locally. We wrote documentation showing other teams how to repeat the setup and which CI/CD changes they would need before taking the Mini Apps into production.

The bank cut release preparation time by 26% in the first release after the monorepo migration. Moving from feature completion to release readiness took 14 days, compared with a historical average of 19 days, shortening the wait before planned banking improvements could move toward rollout.

Before the monorepo migration, feature teams encountered an average of 2.5 problems per release that prevented their changes from being integrated into the app. After the migration, the bank recorded no such blocking issues. A navigation fix was ready for testing in approximately 30 minutes, compared with days for a comparable change under the previous workflow. Shorter feedback loops kept corrections moving through validation and reduced the coordination needed to prepare them for release.

Teams also gained repeatable checks they could run in under a minute: 45 automated integration scenarios across 18 suites. These checks ran on feature and release pull requests, with failing tests stopping the quality workflow before later build stages. Better diagnostics made application issues easier to investigate, while the Platform Team gained time and control to maintain shared tools, dependencies, and upgrades across the app.

Less recurring integration work leaves more engineering capacity for the product roadmap. For the bank, a shorter path to release readiness creates more flexibility to respond to customer needs and competition, and a stronger foundation for getting planned banking improvements into customers' hands sooner.