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
Use this resource inside a path.
The free tools are designed to plug into the larger Salari career system.
