Every Android codebase eventually faces the same question: split it up, or keep stacking features on top of the monolith? The Fragmented podcast explored this question in an episode featuring Ziggy Johnson, who walked through the when, the why, and the "oops, we went too far" of modularization.
The short version: modularization is not a status symbol. It is a tool, and like any tool it either speeds you up or slows you down depending on how and when you reach for it.
- Modularization becomes useful once team size, feature count, or build times start creating friction.
- Feature teams tend to align naturally with module boundaries.
- Over-modularization introduces real costs: coordination overhead, dependency complexity, and indirection multiply.
- Build tools that visualize dependency graphs help manage the resulting structure.
- The transition from monolith to modules is best handled incrementally.
Why teams modularize
The most common driver is build performance. As codebases grow, clean compiles stretch from seconds into minutes. Slow builds erode the number of test cycles developers run daily and interrupt sustained focus.
Ownership is the second driver. As teams expand, multiple people inevitably touch shared packages. A well-defined module boundary gives a feature team a clear area of responsibility, making code reviews easier to assign, on-call rotations simpler to manage, and onboarding faster when each module has a defined purpose.
Where teams go wrong
The failure mode worth naming is over-modularization. Teams sometimes split packages into tiny modules before they have a reason to. The result is a project graph that looks tidy in a diagram but feels punishing to navigate. Build files multiply. Dependencies drift out of sync. A small change in one place suddenly requires updating several modules.
Signs to watch for: modules that exist without clear purpose, dependency cycles that resist simple explanation, and a build graph that new team members cannot quickly understand. When these appear, the modularization strategy itself needs an audit—not more modules.
Tools and techniques
Dependency graph visualizers help teams see the shape of what they have built. These tools expose accidental coupling that text editors hide. Once a tangle becomes visible, refactoring it becomes a concrete task rather than a vague sense that something is wrong.
Incremental migration is the practical path forward. You do not have to rewrite the app in one pass. Pull a vertical slice into a new module, route dependencies into it, verify the build still works, then move the next slice. It is unglamorous work. It also produces code that does not get reverted.
Our analysis
Modularization trades one set of costs for another. The upfront costs are governance, shared understanding of dependency rules, and the discipline to maintain module boundaries from the start. Teams that skip that preparation end up with the worst of both worlds: a slow monolith plus a brittle module graph.
Who wins? Developers on large teams with clear feature ownership get faster builds and cleaner reviews. Who loses? Small teams that modularize prematurely—they absorb governance overhead before they have enough people to distribute it meaningfully.
What to watch over the next year: whether feature-team-aligned modules remain the dominant pattern or whether teams drift back toward layer-based grouping; whether AI-assisted code generation makes module boundaries sharper or more tangled; and whether "monolith with discipline" stays viable for new Android projects or whether module-first becomes the default above a certain codebase size.
The practical question for any team is not "should we modularize?" but "which problem are we solving, and is the team ready to manage the new complexity?" If the answer to the second part is no, start with the smallest possible slice—ideally one self-contained feature—and measure impact before committing further.
Modularization Decision Checklist
- Is build time, team size, or ownership friction currently a blocker?
- Can you articulate the purpose of each proposed module in one sentence?
- Does the team have bandwidth to maintain dependency rules across the graph?
- Is there a self-contained feature you can extract first to validate the approach?
- Can you measure build time or review turnaround before and after to confirm value?
Bottom line
Android app modularization pays off when your team or your build is already strained, and it punishes you when you adopt it before you need to. Start with one vertical slice, watch the dependency graph, and grow the structure only as fast as the team can absorb it.
Frequently asked questions
What is Android app modularization?
It is splitting an Android project into separate Gradle modules, typically aligned with features, to improve build times and code ownership clarity.
When should a team start modularizing?
When build times, team size, or code ownership friction start slowing you down. Splitting too early adds governance costs without proportional payoff.
What is over-modularization?
Creating too many modules before the team size justifies them, resulting in dependency graphs that are hard to maintain and slow to navigate.
Which tools help with modularization?
Dependency graph visualizers expose accidental coupling, and IDE support for navigating between modules keeps refactoring manageable.
Can a team move from monolith to modules incrementally?
Yes. Lift one vertical feature at a time into its own module, verify the build, and repeat. Whole-app rewrites are usually unnecessary.