Spec-Driven Development
For the portfolio CTO whose AI tooling is fast and whose release cadence has not moved — and for the engineering leader looking at the same gap on a smaller team. SDD is GeekByte's operating model for that gap: the structure that puts decisions, not typing, at the center of the work. Open, documented, AGPL-3.0.
Read the SDD Brief
What SDD Is
Spec-Driven Development is a lightweight operating model for engineering teams where human judgment — not human typing — is the scarce resource.
It assumes AI assistance is everywhere in the stack: drafting specs, proposing architectures, writing implementations, generating tests. The methodology’s job is to put structured gates around that work so the organization still accumulates institutional knowledge instead of disposable output.
Three commitments make SDD different from retrofitted Scrum:
Specs before code, always
Two spec types do the work: Feature Specs describe what to change and flow through the pipeline once; Anchor Specs describe how the system is and update deliberately. No change begins without a spec file committed to the repository. A plan in a chat window is not a spec.
Gates you can defend
Four gates run every piece of work from intent to production. At each gate, specialist AI agents produce a structured review and a human operator writes the approval — with reasoning, not just a checkbox.
The reasoning is the artifact
SDD captures why decisions were made, not just what was built. Decision Rationale, Gate Annotations, Post-Completion Retros, Learning Log, Stack Quirks — each is a lightweight mechanism for preserving the context that normally evaporates when people move on.
Who It Is For
PE portfolio CTOs and VPs of Engineering
You have AI tooling across the team. Your individual developer productivity metrics look great. Your release velocity has not moved, and your board is starting to notice. SDD gives you a defensible operating model that survives the next integration and the next reorganization.
Engineering managers running small, fast teams
You do not need heavy process. You need the minimum structure that prevents AI-assisted work from generating technical debt faster than you can review it. Start with the pipeline, add mechanisms as you hit the problems they solve.
Solo operators and independent builders
Every gate is a self-review when you are the only person shipping. SDD’s Solo Operator Model uses specialist AI agents as structured second reviewers so you still get the benefit of a gate, without inventing fictional teammates.
The AI Productivity Paradox
Individual developers are measurably faster with AI assistance. Most teams report 20–30% gains on the tasks where AI helps. And yet release velocity, defect rates, and cycle times have barely moved.
The speed gains do not reach production. They are absorbed by the organizational bottlenecks AI did not touch: decision latency, architectural drift, reviewer overload, and institutional memory loss when code outruns documentation.
SDD is a response to that gap. It moves the structure upstream — to the point where decisions are made and recorded — rather than trying to compress the downstream review lane that is already the bottleneck.
How SDD Fits Into a Growth Advisory Engagement
Most working engineers reading this page found it through search or a peer reference. Some are reading it because their CEO just retained GeekByte for a Growth Advisory engagement and asked you to evaluate the methodology you’ll be working inside.
If you’re in the second group: SDD is the operating backbone of the engagement — the structure your team will use to ship the value-creation plan. The CEO is paying for the engagement; the sponsor sees it as part of the value-creation thesis; you’re the on-the-ground user. The four gates, the four-tier complexity ladder, and the mechanisms that preserve decisions are all calibrated for engineering teams shipping with AI assistance, not for governance theater.
SDD is not a separate product line. It is documented openly because the methodology has to survive team turnover, leadership transitions, and the next sponsor reading it for the first time. AGPL-3.0 licensing reflects that posture: the methodology is shareable, but commercial implementation work is the engagement.
If you want to see what an engagement looks like from the CEO’s perspective — what the CEO is actually buying when SDD shows up on the value-creation plan — read the Growth Advisory page. If you want to see how the methodology runs in practice, the rest of this site is where the work lives.
Explore the Methodology
The Pipeline
Four gates from intent to production. What each gate produces and who owns it.
Complexity Tiers
Trivial, Standard, Complex, Critical. Right-sizing process to the work at hand.
Preserving the Why
Five lightweight mechanisms for capturing reasoning that normally evaporates.
Anchor Specs
Living documents for domain state, synthesized from transactional specs.
Governance
The Solo Operator Model, tier assignment, gate ownership, escalation rules.
Resources
The methodology brief and the learning bundle.