Large Flutter apps often start as a single package where features, networking, analytics, and state management are tightly coupled, slowing CI, making refactors risky, and turning every change into a “whole‑app” operation, especially considering the scalability in which Nubank operates, 135+ million of customers. When codebases reach this point, it is difficult to scale teams, facilitate hundreds of pull requests a month, maintain CI/CD times, and add new features. These issues are amplified with Agentic coding At Nubank, we’ve been evolving a massive, multi‑country Flutter banking app toward a Mobile Destination Architecture: hundreds of packages organized into modules mapping to our architecture layers, with explicit DI contracts that let many squads ship safely on top of shared foundations. This talk distills that experience into a concrete modularization pattern, using pure dependency injection with the main app as a composition root and Riverpod as the wiring layer. This pattern is applicable to any state‑management and DI framework, showing how to move from a monolith to a package‑based architecture, eliminate cycles and unused dependencies, and use explicit interfaces to enable faster CI, safer refactors. Clean Flutter Modularization may also enable non engineers to “vibe code”, and improve AI‑assisted development on large Flutter codebases. Key takeaways: - Design a Flutter modularization strategy across packages, layers, with clear, enforceable boundaries between them. - Implement pure dependency injection in Flutter by treating the main app as a composition root, providing dependencies behind interfaces instead of relying on service locators or global singletons. - Apply the pattern with multiple state management / DI options while still wiring everything cleanly through pubspec.yaml and explicit interfaces. - Leverage AI coding assistants effectively by structuring modules and contracts so serious, large‑scale work fits cleanly into context windows and token budgets. - Improve dependencies management tooling: Avoid common scaling traps such as cyclic dependencies, “god” modules, and hard‑to‑test singletons in large Flutter codebases.