RFC
ar-eff-SEE
A Request for Comments document that proposes a technical change and invites structured feedback from the team.
An RFC (Request for Comments) is a written proposal for a significant technical change. The author describes the problem, proposes a solution, lists alternatives they considered, and invites feedback from the team. It is a decision-making tool that turns hallway conversations into structured, documented discussions.
The name comes from the IETF (Internet Engineering Task Force), where RFCs define internet standards like HTTP and TCP/IP. In software teams, RFCs are used for decisions that affect multiple teams, introduce new technologies, change architectural patterns, or have long-term consequences. Not every change needs an RFC. A bug fix does not. A new microservice does.
The power of an RFC is that it forces the author to think through the problem completely before writing code. Writing "Alternatives Considered" forces you to evaluate other approaches. Writing "Risks" forces you to acknowledge what could go wrong. The feedback process surfaces concerns from people who will be affected by the change but might not be in the room when the decision is made.
Examples
An engineer proposes migrating to a new database.
The RFC outlines the current pain points with MySQL, evaluates PostgreSQL, CockroachDB, and PlanetScale, recommends PostgreSQL with specific benchmarks, details a migration plan spanning three quarters, and lists risks including potential data loss during migration. The team comments asynchronously over two weeks. Three concerns are raised and addressed before any code is written.
A team introduces a new API versioning strategy.
The RFC proposes moving from URL-based versioning (/v1/users) to header-based versioning (Accept: application/vnd.api+json;version=2). It includes compatibility analysis, client migration costs, and a rollout timeline. A backend engineer points out that API gateways handle URL versioning better. The team revises the proposal to use URL versioning with header-based feature negotiation.
A platform team proposes adopting feature flags company-wide.
The RFC evaluates build-vs-buy (LaunchDarkly at $40K/year vs. building in-house at 3 engineer-months). It documents targeting requirements, performance impact (added latency per flag evaluation), and operational burden. The security team requests an audit log requirement. The RFC is revised and approved with a 90-day trial of LaunchDarkly before committing.
In practice
RFC template
RFC: [Title] Author: [Name] | Date: [DATE] | Status: [Draft/Review/Accepted/Rejected] Reviewers: [Names] SUMMARY [1-2 paragraphs: what you propose and why] MOTIVATION [Why is this needed? What problem does it solve? What happens if we do nothing?] DETAILED DESIGN [Technical details of the proposal. Include diagrams, API schemas, data models as needed.] ALTERNATIVES CONSIDERED | Option | Pros | Cons | Why not | |--------|------|------|--------| | [Alt] | [+] | [-] | [Reason] | MIGRATION / ROLLOUT PLAN [How will this be deployed? Feature flags? Phased rollout?] RISKS - [Risk 1]: [Mitigation] - [Risk 2]: [Mitigation] OPEN QUESTIONS - [Question that needs input from reviewers]
Read more on the blog
Frequently asked questions
When should you write an RFC vs just discussing in a meeting?
Write an RFC when the decision is irreversible or expensive to change, when it affects multiple teams, or when you need input from people in different time zones. Meetings are fine for small, reversible decisions. RFCs create a written record of why a decision was made, which is invaluable six months later when someone asks 'why did we do it this way?'
How long should an RFC be?
Long enough to make the case, short enough to get read. Most good RFCs are 2-5 pages. Include: problem statement, proposed solution, alternatives considered, risks, and rollout plan. Skip the background if your audience already understands the context. Amazon's six-page memo format works well for larger proposals. The key is that the reader can evaluate the proposal without needing a meeting.
Related terms
A technical document that describes how a system or feature will be built before implementation begins.
An Architecture Decision Record that documents a significant technical decision and its reasoning.
The gradual, uncontrolled expansion of a project's requirements beyond the original plan.
The practice of having other developers examine code changes before they are merged.
The prioritized list of all planned work that a team has not yet started.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.