RFCs and design docs help you decide should we build this, while SDD specs tell an AI agent how to build it. Used well, classic spec-driven processes have cut code review cycles by an estimated 30 to 40 percent and teams report a 25 percent drop in post-deployment bugs when they don't skip the spec phase.

Most advice on SDD vs RFC / design-docs process gets the argument wrong. It treats them like rival religions. They aren't. They sit at different decision points.

You're also right to be skeptical. A lot of the 2025 to 2026 backlash is deserved. “Waterfall with markdown.” “Productivity trap.” “Spec drift.” “Frozen specs.” “Token-burning ceremony.” All real failure modes. If you write a document because some process cop told you to, you're wasting time. If the doc improves a decision or makes execution sharper, keep it. If it doesn't, kill it.

That's the frame that matters for a solo founder using Cursor, Claude Code, Codex, or Gemini in a real codebase. Human alignment docs and AI execution specs are not the same artifact. Treating them as the same thing is why people either over-document tiny tasks or under-spec the hard ones.

Table of Contents

Stop Debating and Start Building

The SDD vs RFC fight is mostly fake. You don't have a tooling problem. You have a decision problem.

If you're asking whether to use an RFC or an SDD, start with this: what are you trying to reduce? Strategic risk or execution ambiguity? RFCs exist to pressure-test a choice before code starts. SDDs exist to make implementation precise enough that an AI agent doesn't go wandering through your repo like a confused intern.

Most backlash is aimed at the wrong thing

The anti-spec crowd isn't entirely wrong. A bad process turns into ceremony fast.

Here's what usually goes bad:

  • Waterfall with markdown. You write a huge doc, freeze it too early, then pretend reality won't change.
  • Productivity trap. You polish prose instead of cutting code.
  • Spec drift. The doc stops matching the repo after the first real implementation tradeoff.
  • Token-burning ceremony. People write documents to look serious, not to improve outcomes.

The sharp criticism is that many teams judge document quality, not decision quality. That gap is called out directly in this piece on goals and failure modes for RFCs and technical design documents. That's the right complaint. A polished doc that didn't improve the build was still a waste.

Practical rule: If the document didn't reduce rework, clarify tradeoffs, or improve the prompt you hand to your coding agent, it was overhead.

The useful split

For a solo builder, the split is simple.

An RFC answers questions like these:

  • Are you solving the right problem?
  • Is the architecture change worth the blast radius?
  • What alternatives did you reject, and why?
  • Where can this go wrong?

An SDD answers different ones:

  • Which files change?
  • What does done look like?
  • What edge cases must the implementation handle?
  • How do you validate that the code matches the intent?

That distinction matters outside software too. If you're choosing a business model, funding path, or launch route, you still separate the decision from the execution plan. That's why founder resources like best creator funding platforms are useful. First decide which path makes sense. Then define the exact steps.

If you skip that split in software, you get one of two bad outcomes. Either you think forever and ship nothing, or you ship fast into the wrong design.

The Classic RFC and Design Doc Explained

Classic RFCs and design docs came from a human coordination problem. Not an AI prompting problem.

Google is the cleanest example. Design docs became a foundational part of engineering culture in the early 2000s, with a typical sweet spot of 10 to 20 pages for larger projects so busy engineers could still read them. Major changes require a doc that spells out tradeoffs and alternatives, and the process is treated as a core competency for senior engineers in Google's design doc culture.

A five-step infographic showing the standard process for creating RFCs and design documents in a team.

What these docs were built to do

A classic RFC is not just “write down your idea.” It exists to prevent expensive confusion before implementation starts.

At Google, the lifecycle is mature and explicit:

  1. Creation and rapid iteration
  2. Multi-round review
  3. Implementation with iteration
  4. Maintenance with learning

That process matters because the point isn't archival documentation. The point is catching bad assumptions early, building organizational consensus, and spreading senior judgment beyond one person's head.

Stripe follows a similar instinct. The RFC is a forcing function for crisp thinking before people start coding. If you've never built that muscle, it helps to learn software design fundamentals before trying to write “strategy docs” that are really just rambling notes.

What belongs in a real design doc

A good classic design doc does a few things well:

  • States the problem clearly. No hand-wavy “improve the system.”
  • Explains alternatives. Not fake alternatives. Real options you could have chosen.
  • Documents tradeoffs. Performance, reliability, security, scalability, team cost.
  • Invites review before implementation. That's the whole point.

If you want a concrete starting point, use a software design document template and cut it down to what your project needs.

The best RFCs save coding time by preventing the wrong build, not by sounding impressive in review.

For a solo founder, the lesson isn't “copy Google.” It's “borrow the part that catches expensive mistakes.”

The Modern SDD Spec for AI Agents

An SDD spec is not trying to win buy-in from peers. It's trying to reduce ambiguity for a machine.

That changes everything. The audience is now Cursor, Claude Code, Codex, or Gemini working inside a real codebase. So the document can't stay at the “architecture narrative” layer. It needs operational detail.

A hierarchical flowchart diagram outlining the components of an SDD specification document for AI agents.

What makes an SDD different

A useful SDD is more like an execution packet than a position paper.

It should tell the agent:

  • What the goal is
  • What is out of scope
  • Which parts of the repo matter
  • What constraints cannot be violated
  • How success will be checked

That's closer to spec-anchored work than classic review-driven RFC culture. The strength is not discussion. The strength is reducing the amount of discussion needed later.

Stripe's public engineering writing is still useful here because it shows the payoff of getting goals, architecture, and alternatives clear up front. In companies using that kind of spec-driven process, teams saw code review cycles reduced by an estimated 30 to 40 percent in Stripe's RFC approach.

What I'd put in every AI-ready spec

Don't write an essay. Write instructions with enough context to survive implementation.

A solid minimal structure looks like this:

  • Plain-English goal. One paragraph. No jargon padding.
  • Repo-aware context. Name the modules, services, or files likely involved.
  • Constraints. Performance, security, migration safety, backward compatibility.
  • Acceptance criteria. What must be true when the work is done.
  • Validation scenarios. The checks, test paths, and failure cases that matter.

If you want a lean format built for this kind of work, use this minimal spec format.

A vague RFC can still spark a good team conversation. A vague SDD is nearly useless to an AI agent.

That's the whole shift. In the SDD vs RFC / design-docs process debate, the SDD is the execution layer.

Key Differences in an SDD vs RFC

Both are “docs before code.” That's where the similarity mostly ends.

Here's the side-by-side version that matters when you're shipping solo.

RFC vs SDD comparison

Attribute RFC / Design Doc SDD Spec
Primary job Decide whether the approach is worth doing Tell an AI agent exactly how to execute
Main audience Humans, reviewers, stakeholders AI coding agent, then you as reviewer
Best timing Before implementation of non-trivial changes After the direction is chosen, before coding
Scope Strategic, architectural, cross-cutting Tactical, task-level, codebase-grounded
Core content Context, tradeoffs, alternatives, high-level approach Files, steps, constraints, acceptance criteria, validation
Review style Debate, feedback, alignment Clarification, tightening instructions, removing ambiguity
Common failure mode Analysis paralysis Under-specification
Success signal Better decision making Better first-pass implementation
Relationship to ADRs Pre-decision or decision-forming Pre-execution
Ideal length Depends on risk and complexity As short as possible while still precise

Why people confuse them

People confuse RFCs and SDDs because both appear before the code lands. But they answer different questions.

RFCs and design docs are best used before implementation for non-trivial changes with dependencies, because they share context, proposed approach, and tradeoffs while inviting higher-level feedback. They are not the same as ADRs, which are narrower and document a decision after it's made in this explanation of engineering decisions, RFCs, and ADRs.

The failure modes are different

A bloated RFC fails one way. A weak SDD fails another.

RFC failure looks like this:

  • You document every corner case before deciding whether the project is even worth it.
  • You ask for fake “consensus” when nobody else really needs to weigh in.
  • You mistake thoroughness for good judgment.

SDD failure looks like this:

  • You omit repo context, so the agent edits the wrong layer.
  • You skip acceptance criteria, so “done” becomes subjective.
  • You leave edge cases implied, so the implementation breaks in the first weird input path.

My blunt recommendation

Use an RFC when you need to sharpen a decision. Use an SDD when the decision is already made and execution quality is now the bottleneck.

If you try to use an RFC as an AI instruction set, it'll be too vague. If you use an SDD to decide strategy, it'll drag you into premature detail.

When to Use Each and How They Connect

For most solo founders, the answer is not “pick one.” The answer is “use less process, but use the right process at the right moment.”

Start with this split:

A comparison chart highlighting the differences between RFC design documents and SDD specifications for software development.

Use an RFC when the decision itself is risky

You probably need some form of RFC if you're doing things like:

  • Changing architecture. New database, auth model, job system, tenancy model.
  • Making a hard-to-reverse call. Vendor lock-in, schema direction, billing design.
  • Touching a broad blast radius. The change affects multiple flows or important constraints.
  • Working through ugly tradeoffs. Reliability versus speed, simplicity versus flexibility.

For this class of work, a short written decision record before coding pays for itself. The historical pattern is strong. Teams using RFCs and design docs report a 25 percent decrease in post-deployment bugs compared to teams that skip the spec phase, and larger projects commonly take around 2 to 4 weeks to move through creation, review, and implementation in spec-driven workflows.

Use an SDD for most execution work

Most work doesn't need committee theater. It needs clean instructions.

That includes:

  • Feature implementation
  • Bug fixes with edge cases
  • Refactors inside known boundaries
  • API endpoints and UI flows
  • Integration tasks where the architecture is already decided

Watch this if you want another perspective on spec-driven AI development in practice:

The clean layering model

The easiest way to think about it is this:

  1. RFC thought process
    Decide whether the approach is good.

  2. SDD spec
    Translate that decision into executable instructions.

  3. Code review
    Check whether the implementation matches the spec and the repo's reality.

If the architectural choice is obvious, skip the formal RFC and write a tiny decision note. Then move straight to the SDD.

That's the part often missed in the SDD vs RFC / design-docs process discussion. RFCs feed SDDs. They are not competing forms. One narrows the decision. The other sharpens the build.

A Lightweight Process for You and Your AI Agent

Most design doc advice assumes a staffed engineering org. That's not your setup. You have yourself, a repo, and an AI agent that's fast but not trustworthy enough to improvise architecture.

That's why you need a stripped-down process.

Screenshot from https://tekk.coach

The five-line mini RFC

Before you open Cursor or Claude Code, write five lines:

  • Problem
  • Goal
  • Proposed approach
  • Key risk
  • Alternative rejected

That's enough to stop you from coding into a dead end. Nothing more is needed unless the blast radius is large.

Most design doc content is still framed around multi-person coordination. There's much less practical guidance for solo founders who need lightweight, repo-aware specs and still carry the responsibility for architecture and safety. That gap is real, as discussed earlier in the article.

Turn that into an execution spec

Now expand the mini RFC into an SDD your AI agent can use.

Use this checklist:

  • AS-IS state. What exists today? What behavior or structure are you changing?
  • Chosen logic. What exact path should the implementation take?
  • Alternatives. Keep the rejected path visible if the agent might drift toward it.
  • Task breakdown. Split the work into discrete implementation chunks.
  • Acceptance criteria. Make “done” testable in plain English.
  • Validation scenarios. Include edge cases and failure paths.

If you want a practical walkthrough for writing specs this way, this guide on how to write technical specifications is a good starting point.

What this looks like in practice

Say you're adding team invites to an existing SaaS app.

Your mini RFC might say:

  • Problem: Users can't invite collaborators.
  • Goal: Add invite flow without breaking current auth.
  • Proposed approach: Invite token model tied to workspace.
  • Key risk: Bad token handling creates account confusion.
  • Alternative rejected: Free-form email sharing without invite records.

Your SDD then gets concrete:

  • Files likely touched
  • Database changes
  • New endpoint behavior
  • Email flow assumptions
  • Acceptance criteria for invite, resend, revoke, accept
  • Validation for expired or reused tokens

That's enough context for Cursor, Claude Code, Codex, or Gemini to produce something closer to what you want.

Field note: The sweet spot is not “minimal words.” It's “minimal ambiguity.”

How to Adopt This Process Today

Don't redesign your whole workflow. Test this on your next task.

Do this on the next feature

  1. Write a mini RFC first. Open a text file and write the problem, goal, proposed fix, and one rejected alternative.
  2. Expand it into a small SDD. A strong design doc should cover the AS-IS state, alternatives, chosen logic, and task breakdown so the plan can be validated against performance, scalability, security, and reliability in this practical design doc benchmark.
  3. Paste that SDD into your coding agent. Ask for implementation based on the spec, not based on a vague feature request.
  4. Judge the result. Was the first pass closer? Did review get easier? Did you catch a bad idea before coding?

If you're already experimenting with agent workflows, this piece on optimizing code with Claude AI is worth reading because it focuses on practical working habits instead of hand-wavy hype.

Don't overcomplicate this. If the task is small, your RFC is tiny. If the task is risky, spend longer on the decision. Then write the execution spec and ship.

Connect your GitHub repo. Describe the problem. Get a structured spec. Ship with Tekk.coach.

Part of the Spec-Driven Development pillar — a 52-page honest playbook on shipping with AI coding agents.