Phase 6 step-by-step
Create a principal-level mobile platform strategy.
Outcome: a three-year Android/mobile strategy that executives, directors, staff engineers, and feature teams can actually use.
DirectionNative, KMP, Flutter, web, or hybrid investment.
EconomicsBuild, buy, defer, or reject.
GovernanceDecision rights and policy.
RiskReliability, security, hiring, platform drift.
Write the business context
Start with business constraints, not architecture preference.
Business context: - Mobile drives 68% of user sessions. - Android supports low-end devices in tier-2 and tier-3 cities. - Release confidence is low near campaign launches. - Hiring senior Android engineers is slow. - Product needs faster experimentation without reducing reliability.
Checkpoint: the strategy can be understood without knowing Android internals.
Audit technical current state
| Architecture | Native Kotlin, mixed XML/Compose, duplicated platform utilities. |
|---|---|
| Quality | Crash monitoring exists, but ANR and startup ownership are weak. |
| Delivery | Release train is predictable but rollback confidence is inconsistent. |
| People | Feature teams depend on a few senior Android reviewers. |
Compare strategic options
| Option | Use when | Risk |
|---|---|---|
| Native Android | Platform integration and performance matter. | Separate iOS investment needed. |
| KMP | Shared business logic is stable and cross-platform. | Org must handle shared ownership. |
| Flutter | New product surface, shared UI, controlled scope. | Migration cost and native integration risk. |
| Web/PWA | Low device integration and fast distribution matter. | Native UX and offline limits. |
Choose investment posture
Recommendation: - Keep core app native Android. - Use Compose-first for new Android UI. - Evaluate KMP only for stable business rules, not UI rewrite. - Fund platform reliability lane for two quarters. - Reject full cross-platform rewrite until economics change.
The recommendation is specific enough to fund, defer, or reject work.
Define governance
- Architecture review required for shared platform APIs.
- Feature teams own local implementation inside approved boundaries.
- Every shared module has an owner and deprecation path.
- Security/privacy review required before collecting sensitive data.
- Exceptions expire and must be re-approved.
Create the investment model
| Investment | Cost | Payoff |
|---|---|---|
| Platform reliability lane | 2 engineers for 6 months | Lower release risk, faster feature teams. |
| Design system cleanup | 1 engineer + designer for 1 quarter | Less duplicated UI and better accessibility. |
| Full rewrite | High, multi-quarter | Rejected unless current app becomes unmaintainable. |
Write the executive memo
Decision memo: We should fund Android platform reliability for H1. Reason: Feature delivery is slowing due to duplicated infrastructure and low release confidence. Trade-off: Two engineers will not ship feature work directly during this period. Expected result: Improved release confidence, lower duplicated code, faster onboarding, clearer ownership. Decision needed: Approve platform lane and success metrics by end of planning cycle.
Maintain the risk register
| Risk | Signal | Response |
|---|---|---|
| Architecture drift | Teams duplicate platform code | Platform review and exception expiry |
| Release fragility | Hotfix rate increases | Rollback drills and staged release policy |
| Hiring bottleneck | Senior reviewers overloaded | Review rubric and mentorship rotation |
| Accessibility debt | Core flows fail audits | Accessibility gate before release |
Principal-level failure modes
Strategy is a preference essayConvert preference into funded choices, rejected options, and measurable outcomes.
No economic modelLeaders need cost, trade-off, and timing, not only technical correctness.
Governance blocks teamsGovern shared decisions; do not centralize every implementation choice.
No successionA platform that depends on one principal engineer is not healthy.
Completion gate
- Strategy starts from business context.
- Options are compared with explicit trade-offs.
- Investment model names cost and payoff.
- Governance defines owners and exceptions.
- Risk register has signals and responses.