All resources
template
Mobile architecture RFC template
A mobile architecture RFC template that forces the decision to show constraints, rejected options, rollout risk, ownership and rollback.
Use this in practice
Use this when a decision is too expensive to leave in Slack. The RFC should make future readers understand the problem, the tradeoff and the cost of being wrong.
Copy this structure
- Title: name the decision, not the solution. Example: Image loading ownership and cache policy, not Use Library X.
- Status: draft, reviewing, approved, superseded or rejected. Include date and decision owner.
- Problem: what is broken now, who feels the pain, how often it happens and why the current approach cannot continue.
- Goals: the measurable things this decision must improve, such as launch time, crash rate, build time, feature delivery or correctness.
- Non-goals: what the RFC will deliberately not solve, so the review does not expand forever.
- Constraints: app version support, release calendar, team ownership, privacy, migration cost, dependency policy and platform limitations.
- Options considered: at least three, including do nothing. Describe each option fairly enough that opponents recognize their argument.
- Recommendation: the chosen option, the tradeoff you accept and the reason it fits the constraints better than the alternatives.
- Rollout: phases, owners, feature flags, migration path, QA focus and rollback criteria.
- Risks: what can go wrong, how you will detect it and what you will do if it happens.
Review questions
- Could a new engineer understand why this decision was made six months later without asking the original author?
- Does the RFC explain the cost of doing nothing, or does it only sell the preferred option?
- Are rejected options described with enough respect that the review feels honest?
- Is the owner after approval clear, including who maintains docs, migrations and follow-up work?
- Can the decision be rolled out gradually, measured, paused and reversed?
- Does the RFC describe user risk, release risk and team risk separately?
- Is there a smallest valuable version, or does the plan require a risky all-at-once migration?
Bad RFC smells
- The RFC starts with a tool instead of a problem.
- Every alternative is made to look obviously worse.
- There is no explicit owner after approval.
- The rollout plan says migrate gradually but does not name phases, flags or success checks.
- The risks section contains only generic phrases like complexity, maintenance or performance.
- The decision cannot be evaluated after shipping because no metrics or checkpoints were defined.
Go deeper
Mobile System Design blueprint
Practice the decisions behind evolving, migrating, releasing and operating real mobile systems.
Altitude - the missing bridge between senior mobile Engineer and staff Engineer
Think like a staff-level mobile systems engineer across client, backend, security, reliability and production tradeoffs.
Use this resource inside a path.
The free tools are designed to plug into the larger Salari career system.
