Feature Driven Design: Microfrontends’ Best Friend (Chase App)

Jurek traces how a React Native project can grow from a simple app structure into a monolith divided by screens, hooks, and helpers. That approach can work for a small project, but becomes difficult for larger teams: builds take longer, defects are harder to trace, and teams can conflict when changing shared code.

Chase’s shared packages had confusing exports and cyclic dependencies, which made behavior and builds unpredictable. Moving files to break cycles reduced some problems but grew the project to more than 80 packages, making ownership and testing difficult. Changes to core packages could require coordinated releases across nearly the whole project.

Jurek proposes grouping the project around product areas such as Mobile Home, Mobile Chat, and Mobile Accounts. Teams can own those areas, while shared flows and utilities are organized by their feature origins, such as Shared Payments or Shared Onboarding. She says this approach reduces package count and relationships.

A payment flow can be reused inside account closure, while its origin remains Shared Payments rather than the feature that launched it. The same principle applies to utilities: a UK mobile number sanitizer first used in onboarding belongs with that feature even if servicing later uses it. This makes code easier to locate and ownership clearer.

Jurek says feature-driven organization gives teams clearer CI errors, stronger ownership, and room to decide when a feature is ready to release. It also creates a shared vocabulary for developers, designers, and product owners. Packages can be deployed with fewer internal dependencies, reducing the burden on teams that consume them.