Tailoring Flutter Architectures for Team and Business Success
summary
Joined a 100k+ user Flutter app and spent two years iterating architecture to prioritize developer speed over early perfection, standardizing naming and folders, unifying state libraries (migrating from Bloc->Box consolidation), and enforcing DI layers and a code contract for a three‑developer core team. Actions include a dependency audit, parallelized refactor tasks on the board, and cutting the test runner from ~2 minutes to under 30 seconds. Result: steadier delivery cadence and a predictable codebase achieved without visible business disruption. naming & directory cleanup
AI-written summary · about
chapters (18)
- 0:00Introduction
- 2:14Startup architecture failures
- 4:03Speed vs developer experience
- 6:38Preparing for changes
- 8:23Naming and structure
- 11:58Cleaning dependencies
- 14:03Refactoring goals
- 15:57Parallel development tools
- 17:32CI/CD optimization
- 18:42State management
- 21:35Personal vs team balance
- 23:03Coding standards
- 24:32Onboarding guidelines
- 26:22Team meetings
- 27:51Test coverage for speed
- 28:34Trade-offs and solutions
- 30:01Tailoring architecture
- 31:51Conclusion
related talks
37mTaming Legacy: Refactoring Patterns for Large Flutter Codebases
45mFlutter: A journey of productivity and happiness
35mTaming Legacy: Refactoring Patterns for Large Flutter Codebases
44mMultimodule Flutter App
22mClean Architecture in Flutter for Maintainable Code
30mFlutter at scale-experience from 25+ Flutter Devs working together on a mobile banking app
42mOur Journey to Flutter
25mNative to flutter: A tale of Tide's transformation