I broke a single-module Android app into a core/feature module structure — same functionality, same screens — and measured the difference on an incremental build (touch one file, rebuild).
Monolith: 3.744s. Modularized: 2.614s. That's ~30% faster, compounding every time a dev on the team touches one feature.
Repo has both versions (main and monolith-baseline), so you can reproduce the comparison yourself.
Stack: Kotlin, Compose, Hilt, Gradle version catalogs.
Repo: https://github.com/ranab4b/android-modularization-blueprint
Top comments (1)
Reproducible baseline branches are rarer than they should be, so credit for
monolith-baselineexisting. The number I'd interrogate before extrapolating the 30%: how much of the delta is Gradle's per-module overhead versus real work skipping? On small apps I've seen the config phase grow with module count eat most of the execution-phase win, which means the break-even depends on team size more than app size. Was the configuration cache on for both runs, and how many feature modules ended up in the split?The payoff I actually felt after modularizing wasn't the wall-clock number, though — it was compile-time enforcement: a feature that tries to reach into another feature's internals simply doesn't compile, so the architecture stops relying on review discipline. Did you wire the api/implementation boundaries to make illegal edges fail the build, or is that still a convention for now?