Building a large-scale Flutter mobile banking application with 25 Flutter Devs
summary
A banking app with over 25 Flutter developers and 200+ people uses a mono repo and domain-oriented packages to keep ownership clear, assigns every package to a team, and enforces approvals for external changes. Tooling includes Melos for multi-package tasks and unified linting, and a homegrown UI test framework Patrol after Appium proved unstable. Design system has 350+ components, tokenized colors and typography, Storybook and golden tests; the app ships and supports multiple themes and automated visual regression checks.
AI-written summary · about
chapters (11)
- 0:00Introduction to Flutter at Scale
- 1:08Defining small vs large projects
- 2:33Project scope and team structure
- 3:57Concept one code ownership
- 8:16Project structure and Conway's Law
- 12:54Multi-package environment tools
- 14:38End-to-end integration testing challenges
- 16:42Design system necessity and tokens
- 26:58Golden tests for visual regression
- 30:32Storybook for component isolation
- 33:23Q&A and additional resources
related talks
30mFlutter at scale-experience from 25+ Flutter Devs working together on a mobile banking app
44mMultimodule Flutter App
45mFlutter and a Large Project — Who Wins?
31mFlutter with 50+ Engineers
36mFlutter Add-to-App: The Good, the Bad and the Ugly
37mTaming Legacy: Refactoring Patterns for Large Flutter Codebases
37mFlutter at scale
35mTaming Legacy: Refactoring Patterns for Large Flutter Codebases