An account module became the safe place to start.

The module challenge

Profile data, session state and linked screens had to gain one clear owner while both apps kept shipping weekly.

Platform: iOS + Android
Module: Account & identity
Release strategy: Parallel route + fallback

A developer testing one account module across two mobile platforms — Module in focusAccount, profile and session ownership across both apps

Inside the boundary

Account & identity

Small enough to control. Important enough to prove the approach.

The account journey was a useful first module because customers used it every day, several product areas depended on it and the team already had feature work planned. It created a real test of whether a new boundary could survive production—not a disconnected technical demo.

The boundary included profile screens, session state, account services and navigation into the journey. Checkout, orders and the existing authentication provider stayed outside it. Those edges made the migration measurable and kept the first release deliberately contained.

Inputs

Session, profile API, navigation

Owns

Account UI, state and tests

Outputs

Profile updates and route events

The product moved fast. Account code pushed back.

Profile data was read and changed from several screens. Session handling lived partly in shared app code and partly inside view controllers, while navigation decisions depended on callbacks that were hard to follow. A change to one account screen could unexpectedly affect checkout, orders or sign-in.

The issue was not simply that the UI was old. The module had no enforceable boundary: screens could reach shared services directly, tests needed too much of the app to run and no single team could explain the full release risk. Rewriting a few views would have preserved the same underlying problem.

Prove the new boundary in one live user journey.

The work started by agreeing what the account module would own, which behaviours could not change and where the old app was still allowed to call in. Only then did the team replace implementation details.

Review

Trace data and routes

Map every account entry point, profile mutation and session dependency. Turn hidden coupling into a short contract the product and engineering teams can review together.

Build

Create native module shells

Place SwiftUI and Compose implementations behind the same module interface. Keep authentication and backend contracts stable while moving state ownership behind the boundary.

Prove

Release with a fallback

Route a controlled group into the new journey, compare errors and completion behaviour, and retain the old route until production evidence supports increasing exposure.

The team gained a pattern it could use again.

The most useful outcome was not a set of new account screens. It was a working example of where state lives, how old and new code communicate, and what evidence is required before a module takes more traffic.

Clear ownershipThe account feature gained one home for its screens, state, navigation rules and focused tests.

Safer deliveryThe new route could be enabled gradually and disabled without backing out unrelated weekly product changes.

Reusable boundaryCheckout and orders could adopt the same interface, release checks and ownership model without copying account code.

Illustrative module study. It blends recurring delivery patterns from similar projects and does not represent a named client claim.

Next module study Onboarding & consent module