What is an RFC — the engineering proposal process that gets alignment before building.
Short answer
In software engineering, an RFC (Request for Comments) is a structured proposal document that solicits feedback from peers before a significant technical change is made. Unlike a design doc (which documents how something will be built after the decision is made), an RFC explicitly invites dissent and alternative proposals before the decision is final. RFCs are used by Rust, React, Ember, and many large engineering organizations for significant architectural or API changes.
The RFC process in software engineering was adapted from the IETF (Internet Engineering Task Force) process, which has used RFCs to standardize internet protocols since the 1960s. In software companies, internal RFCs serve a different purpose: distributed decision-making on significant technical changes.
Why RFCs exist. Large engineering organizations can't run every significant technical decision through a central architecture committee — it's too slow. RFCs distribute the process: anyone can propose a change, peers review and comment, the community reaches rough consensus, and the proposal is accepted, revised, or rejected. The process is visible and documented, creating a searchable record of why technical decisions were made.
When to write an RFC (vs. just a design doc). Write an RFC when:
- The change affects multiple teams or codebases
- The decision is reversible only at high cost
- There are genuinely multiple viable approaches and the best isn't obvious
- The change introduces a new pattern that will be widely followed
Write a design doc (not an RFC) when the approach is clear, the scope is bounded, and you're documenting how, not seeking input on whether.
The RFC format (varies by organization, common sections):
- Summary — one paragraph explaining the change and its motivation
- Motivation — why this change is needed and what problem it solves
- Detailed design — the technical specifics of the proposed change
- Alternatives considered — other approaches evaluated and why each was rejected
- Drawbacks — honest assessment of the downsides of this proposal
- Unresolved questions — open issues the RFC author wants input on specifically
- Implementation — how the change would be rolled out
The review process. RFC is opened as a pull request or shared document with a defined comment period (typically 2–4 weeks for significant changes). Team members comment, propose alternatives, and raise concerns. The RFC shepherd (often the author) synthesizes feedback and either revises the proposal or prepares a disposition summary explaining which feedback was incorporated and why other feedback was not. Final decision is made by the RFC shepherd or a designated decision-maker.
Famous RFC processes. Rust's RFC process is the most well-documented — every significant language change goes through it, and the RFC repository is public. React, Ember, and Vue all use similar processes for major API changes. Many large companies (Stripe, Shopify, Airbnb) have internal RFC processes for cross-team architectural changes.
When an RFC concept is first sketched at a whiteboard, snap it with BoardSnap. The AI reads the problem statement, proposed design, and alternatives and produces a first-draft RFC structure ready for the engineering team.
Frequently asked
What does RFC stand for?
Request for Comments. In its original IETF usage, RFC is a type of document used to specify internet standards and protocols — RFC 2616 is the original HTTP/1.1 specification. In software engineering organizations, RFC has been repurposed to mean any structured proposal document that solicits feedback before a significant change is made.
How is an RFC different from a design doc?
A design doc documents how something will be built, typically after the decision to build it has been made. An RFC is a proposal seeking input on whether and how to make a change — it explicitly invites alternatives and dissent. RFCs are used when the decision is not yet made; design docs document decisions already reached.
Do all companies need an RFC process?
No. Very small teams (under 10 engineers) typically don't need a formal RFC process — they can align in a meeting. RFC processes become valuable when teams are large enough that decisions made by one team affect others without awareness, or when the pace of change makes informal alignment impractical. The overhead is justified once you've had at least two significant "we didn't know that was changing" incidents.
See it work in ten seconds.
BoardSnap is free on the App Store. Snap a board — get a summary and action plan.