What is Spec-Driven Development?
Spec-driven development (SDD) means writing a formal specification before any code is written. The spec — not a chat thread, not a Notion doc, not a verbal agreement — is the single source of truth that both humans and AI agents work from.
Tools like GitHub Spec Kit, AWS Kiro, and OpenSpec have made this practical: you write a structured spec, the AI agent reads it, generates a plan, and builds exactly what the spec says. No more 'vibing' your way through a build.
The Missing Piece: Client Sign-Off
Here's what every SDD tutorial skips: the spec is only useful if your client has agreed to it. An unsigned spec is just a wish list with formatting.
In client work, spec-driven development has three phases that open-source projects don't have: (1) extracting the spec from client conversations, (2) getting the client to read and sign the spec, and (3) managing spec changes as paid change orders — not free rework.
- Phase 1: Extract — turn chats, emails, and voice notes into structured requirements
- Phase 2: Confirm — client signs off line by line (not a blanket 'looks good')
- Phase 3: Evolve — every spec change becomes a change order with impact analysis and pricing
How to Extract a Spec from Client Conversations
Clients don't write specs — they describe symptoms, compare to competitors, and change their minds. Your job is to turn that chaos into a structured spec. Here's the workflow that works:
Start by collecting everything: chat logs, voice memos, screenshots of competitor apps, forwarded emails. Don't filter yet — you're mining raw material. Then use an AI tool to extract candidate requirements, each tagged with its source quote. This gives you traceability: every requirement links back to what the client actually said.
- Collect all client communications in one place
- Extract requirements with source attribution (who said it, when)
- Flag ambiguities as clarification questions — don't guess
- Classify each requirement: confirmed / inferred / needs-clarification
Getting the Client to Actually Read the Spec
A 40-page spec document will not get read. Ever. Instead, present the spec as a numbered checklist: one line per requirement, grouped by feature area. Ask the client to confirm or reject each line individually.
This 'line-by-line sign-off' approach has a 10× completion rate compared to 'please review the attached document'. Why? Because rejecting line #23 is easy — reviewing a 40-page doc is not. The client feels in control; you get explicit approval on every scope item.
When the Spec Changes (It Will)
Spec changes are not a failure of SDD — they're a feature. The whole point is that when the spec changes, you have a baseline to diff against. Without a baseline, 'change' is indistinguishable from 'the original request'.
The correct workflow: (1) Client requests a change. (2) You assess impact — which existing requirements are affected? (3) You generate a change order with the scope delta and price adjustment. (4) Client signs the change order. (5) Spec is updated, agent rebuilds from the new version.
This is where tools like BriefPort earn their keep: they freeze the baseline, automatically detect what changed, and generate a client-ready change order with impact analysis. Without a tool, you're maintaining spreadsheets and hoping.
Spec-Driven Development vs. Vibe Coding for Client Projects
Vibe coding — prompting an AI agent until the output feels right — is perfect for prototypes and personal projects. For client work, it's a recipe for disaster: no baseline, no sign-off, no change control, and no way to prove what was agreed.
Use vibe coding for exploration. Use spec-driven development for delivery. The spec is your contract; the AI agent is your builder; the change order is your invoice.
Tools Comparison: Spec Kit vs. Kiro vs. OpenSpec vs. BriefPort
GitHub Spec Kit (72k stars), AWS Kiro, and OpenSpec are excellent developer-side SDD tools — they structure your spec and guide the agent. But none of them solve the client-facing problems: sign-off, change orders, and progress visibility.
BriefPort is the client-side complement: it sits between your client and your spec-driven workflow. You extract requirements from client conversations, get line-by-line sign-off, freeze the baseline, and manage changes as priced change orders. Your Spec Kit / Kiro / Claude Code agent reads the frozen baseline and builds against it.
Getting Started
Ready to try spec-driven development for your next client project? Start simple: (1) Use a clarification checklist to capture all requirements before you build. (2) Present requirements as a line-by-line checklist for client sign-off. (3) When the client requests a change, generate a change order with impact analysis. (4) Point your AI agent at the signed baseline.
You'll never go back to 'I'll just build it and hope they like it'.