As an iOS app grows beyond a single team, a monolithic codebase stops being an asset and starts being a liability - merge conflicts multiply, build times balloon, and nobody is quite sure who owns what. Splitting into modules is the obvious answer, but the decisions you make early about where to draw boundaries, how to wire dependencies, and what architecture pattern to put inside each module have compounding effects that are very hard to undo at 3,000 files. This talk walks through the real architectural decisions behind a production banking app split across 45 Swift modules and 3,800 files — what we got right, what we got wrong, and the specific patterns that let a growing team ship features independently without stepping on each other. I will cover the Router–Interactor–Builder pattern we use in place of MVVM or TCA, how we enforce module boundaries and prevent circular imports, and the honest impact modular architecture has had on build times and developer experience.