Solo RFC

A structured decision-making process for solo developers. Prevents over-engineering by requiring problem-first thinking before adopting new tools, patterns, or infrastructure.

Workflow

Execute these four stages in order. Do not skip stages. Each stage produces a specific output before moving on.

Stage 1: Problem Framing

Goal: A crisp 1-2 sentence problem statement.

Ask the user to articulate the actual problem, not the solution they're considering. Many technical decisions start from "I should add X" rather than "I'm struggling with Y." This stage forces the reframe.

Ask clarifying questions:

• What's painful right now? What specific friction are you hitting?
• Who or what is affected? (Just you? Users? CI? Deployments?)
• What happens if you do nothing for the next 3-6 months?
• How often does this pain actually occur?

Push back gently if the user jumps to solutions. Redirect with: "Before we evaluate that option, let's nail down what problem it would solve."

Conclude this stage by writing out a clear problem statement and confirming it with the user.

Stage 2: Research & Options

Goal: A grounded list of options with honest trade-off assessments.

Explore the codebase

Before researching solutions, understand what already exists:

• Current project structure, tooling, and configuration
• Existing patterns that relate to the problem
• Scale indicators: number of packages, contributors, release frequency, project maturity

Use subagents for parallel research when investigating multiple options.

Build the options list

For each option, assess:

• What it solves: Which parts of the problem statement does it address?
• What it doesn't solve: Be honest about gaps
• Complexity introduced: New dependencies, config files, CI changes, learning curve
• Maintenance burden: Ongoing cost of keeping it working
• Fit for current scale: Is this designed for a scale you haven't reached?

Always include "Do nothing / minimal manual approach" as Option A. This is the core anti-premature-complexity mechanism. Describe what "do nothing" actually looks like in practice - it's rarely as bad as it seems.

Challenge assumptions throughout:

• "Is this solving a problem you have, or a problem you might have?"
• "How many times has this actually bitten you?"
• "What's the manual workaround, and how painful is it really?"

Stage 3: Decision

Goal: A clear decision the user is confident in.

Present a comparison of options. Include a recommendation with reasoning. Apply the complexity filter: "Is this the simplest thing that could work for your current scale?"

Frame the recommendation honestly:

• If "do nothing" is genuinely the best option, say so clearly
• If a tool is warranted, explain what's changed that makes the complexity worth it
• If the answer is "not yet," suggest a trigger point: "Revisit when X happens"

Get the user's explicit decision before proceeding to documentation.

Stage 4: Document

Goal: A persistent decision record in the project repository.

Write the RFC document using the template in references/rfc-template.md.

Save to: docs/decisions/RFC-YYYY-MM-DD-title.md (using today's date and a kebab-case title derived from the problem).

Create the docs/decisions/ directory if it doesn't exist.

This document serves as future reference for "why did we do it this way?" - valuable context when revisiting the decision later or when onboarding collaborators.