What we build with it
Every Flutter app has a Gradle build underneath its Android half, and it stops being invisible the moment a product needs more than one variant. Product flavours for staging and production, separate signing configurations, per-flavour application IDs, resource overrides, and whatever native SDKs the app pulls in.
That is also where the awkward problems live: dependency conflicts between plugins, minification rules that strip something reflection needed, and build failures that only happen in release mode.
Where it fits
Under the Android side of our mobile work, and closely tied to Kotlin when an app has native code, and to Fastlane, which drives these builds from CI rather than from a developer's machine.
It matters most on multi-target products. A white-label platform producing many branded apps from one codebase is really a Gradle configuration problem as much as a Flutter one — each brand needs its own identifier, assets and signing identity, generated rather than hand-maintained.
When we recommend it
It is not optional for Android; the choice is only whether to treat the build as code. We do — flavours declared once and derived, not copy-pasted per brand.
Where we keep it minimal is custom Gradle plugins and bespoke task graphs. They are powerful and they are also the thing nobody on the team wants to debug two years later, so we reach for them only when a real problem demands it.