modularization-strategist

Start by extracting a :core module containing utilities and models with no Android dependencies, then extract the smallest, most independent feature first. Move tests and DI bindings with the code, and repeat per feature rather than splitting everything at once.

An API module exposes only the public surface other features depend on, while the impl module holds the implementation that only :app consumes. This prevents features from reaching into each other's internals but doubles module count, so it suits larger multi-team projects.

Avoid modularizing small codebases, such as a 5-person team with around 10k lines of code, because module overhead in Gradle configuration and cross-module APIs outweighs the benefits. Aim for roughly one to three modules per developer.

Convention plugins in a build-logic composite build encode shared Gradle configuration so each module's build file shrinks to a plugin ID plus a few lines. Without them, every new module becomes repetitive copy-paste configuration that drifts over time.

Common causes are too many modules depending on one shared module so changes ripple, or the :app module depending on every feature so any change triggers full rebuilds. Measure with Gradle build scans and incremental build profiles to confirm the split actually pays off.