Android
AuraScore 79/100

Android Modularization Architecture Advisory Email

Advise client engineering leadership on transitioning legacy monolithic Android applications to scalable, feature-driven multi-module architectures.

Use this template when consulting for enterprise clients struggling with slow Gradle builds, code ownership conflicts, and tight coupling across Android codebases. It generates an executive-ready architectural recommendation email covering dependency injection, navigation, and module isolation.

Template

Role: Principal Android Solutions Architect advising enterprise professional services clients on codebase modernization.

Context

  • Client organisation: {{client_organization}}
  • Existing monolithic app scope: {{monolith_app_scope}}
  • Target architectural pattern: {{target_architecture}}
  • Primary build and CI bottleneck: {{build_time_bottlenecks}}
  • Engineering governance framework: {{governance_framework}}
  • Client delivery schedule: {{migration_timeline}}

Task

Draft a high-impact technical advisory email to the client's engineering leadership outlining the strategic transition from their existing monolithic Android codebase to an enterprise-grade multi-module architecture, resolving build latency and delivery bottlenecks.

Method

  1. Analyze {{monolith_app_scope}} to identify high-coupling domain clusters, shared state hazards, and circular dependencies.
  2. Correlate current {{build_time_bottlenecks}} with Gradle build configuration issues, dynamic feature module feasibility, and dependency graphs.
  3. Formulate the target boundary definitions based on {{target_architecture}}, distinguishing feature modules, core platform modules, and contract libraries.
  4. Define migration guardrails using {{governance_framework}} to safeguard active release velocity during refactoring.
  5. Establish dependency injection and Jetpack Compose navigation patterns suited for isolated feature development.
  6. Structure a phased execution path aligned with {{migration_timeline}}, highlighting pilot module candidates.
  7. Detail team enablement initiatives, developer onboarding protocols, and incremental CI pipeline optimization milestones.

Constraints

  • MUST structure the deliverable as a polished, executive-ready advisory email with professional markdown formatting.
  • MUST NOT prescribe complete ground-up rewrites; focus on incremental, low-risk modularization.
  • MUST include explicit technical guidance on Gradle configuration cache, remote build caching, and API vs. implementation scoping.
  • Keep communication authoritative, transparent, and direct.

Output format

  • Subject line: Actionable, executive-level subject.
  • Executive Summary: Context, primary rationale, and expected business ROI (max 150 words).
  • Architectural Blueprint: Module hierarchy, navigation strategy, and DI structure.
  • Risk & Build Optimization Plan: Concrete tactics for mitigating {{build_time_bottlenecks}}.
  • Phased Roadmap: Phase 1 through Phase 3 milestones under {{migration_timeline}}.
  • Next Steps: Immediate 14-day technical decisions required from the client.

Self-review

  1. Did I address the specific architectural parameters in {{target_architecture}}?
  2. Are the proposed mitigations directly resolving {{build_time_bottlenecks}}?
  3. Is the tone appropriately calibrated for enterprise professional services advisory?
AuraScore breakdown
79/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-android
professional-services
android
modularization
architecture