Reshaping Mobile Bank Development for Business

The original team of roughly fifty people combined product and engineering roles and used shared prioritization. Large releases contained a predetermined set of features, with dates slipping when work remained unfinished. A separate API team followed its own processes, so mobile development waited for the required methods to be designed and implemented. This arrangement suited earlier priorities but constrained parallel product development.

The new model introduced teams aligned with business areas and platform teams responsible for shared tools and rules. Scheduled release trains replaced the need to wait for every planned feature. Working on the main branch with feature flags allowed only completed functionality to be enabled. Organizational autonomy also required technical boundaries: it would not work if every change still affected an undivided codebase.

The application was divided into shared and product-specific modules. Platform teams owned common capabilities such as data access, API integration, dependency injection, and utilities. Product teams owned modules for their business scenarios. Within a module, presentation, domain logic, and data access were separate, with the domain layer independent of the other two.

A module without a user interface could expose use cases to other modules. One with its own screen could keep its domain logic private. Teams gradually extracted their code from the monolith. The target ability to build a smaller application from shared modules and a team's own modules would speed up local development and testing. Unlike server microservices, these mobile modules did not become independently running applications on the device.

Replacing uneven checklists with explicit test cases exposed a backlog of missing coverage, described as test debt. Developers and testers jointly built automated tests at unit, integration, UI, and end-to-end levels. Metrics tracked both product quality and progress on this work. Crowdtesting through the internal Klex platform and contract checks against upstream systems were described as pilots, rather than established results.

More teams and tests produced more builds and infrastructure load. Pipelines needed to become faster, enforce technical rules, and support monitoring on users' devices. Remote feature flags helped control when changes were enabled. The central lesson is that teams, architecture, quality practices, and infrastructure must evolve together: splitting a monolith alone does not produce autonomous teams or reliable product releases.