MVP vs Specification: how Spec-Driven Development fixes the "Quick Ship" bias

The startup mantra is well known: "ship fast, learn fast". Build an MVP in weeks, put it in front of users, iterate. The problem isn't the speed. The problem is what happens when that MVP, built on undocumented assumptions, has to scale, integrate with AI agents or survive the first pivot. 80% of software rework originates from requirements defects. And an MVP without a specification is, by definition, a product built on implicit requirements.

Spec-Driven Development (SDD) doesn't propose a return to waterfall or writing 100-page documents before you code. It proposes something more precise: documenting the decisions you're already making, in a format both humans and AI agents can consume. The difference between an MVP that validates and one that generates months of rework lies, almost always, in those unwritten decisions.

The hidden cost of MVPs without a specification

When a team builds an MVP under time pressure, a predictable pattern emerges: requirements get assumed instead of documented. The frontend assumes a data structure. The backend assumes a user flow. QA assumes acceptance criteria. And nobody discovers the inconsistencies until 3-5 weeks later, when the pieces don't fit.

The data is stark:
- 30-50% of total effort on software projects goes to rework (Boehm & Papaccio)
- 80% of that rework is attributable to requirements defects (Info-Tech Research Group)
- A requirements error costs 8x more to fix in design, 16x in code and 29x in production (NASA)
- Every euro invested in improving requirements processes returns between 3x and 7.5x (Carnegie Mellon SEI)

In a typical 8-12 week MVP, this translates into an additional 3-5 weeks of unplanned redesign. Not because the team is bad, but because undocumented assumptions diverge from person to person. And when you introduce AI agents into that process, the problem multiplies.

Why AI amplifies the problem

An AI agent like Claude Code or GitHub Copilot has no intuition. It doesn't "know" the CTO wanted a two-step checkout flow, not three. It doesn't infer that the API should be RESTful because the mobile team needs it. Without a specification, the agent generates code based on statistical patterns, not product decisions.

When teams with immature requirements processes bring in AI, they don't reduce rework: they accelerate it. As Thoughtworks notes in its SDD analysis for the Technology Radar, AI produces wrong solutions faster when it has no specifications to guide it. The result is more code to refactor, not less.

When a specification is "formal enough" for AI

The "Quick Ship" bias assumes that specifying is the opposite of being agile. That writing a spec before you code is wasted time. But a specification that's useful for SDD looks nothing like a 100-page requirements document. It looks like this:

## Feature: Simplified checkout

### Problem
34% of users drop off at the payment step.
We need to reduce friction without compromising security.

### Constraints
- Maximum 2 steps (details + confirmation)
- Gateway: Stripe (already integrated)
- Do not store card data (PCI compliance)
- REST API, endpoint POST /api/checkout

### Acceptance criteria
- [ ] User completes purchase in under 60 seconds
- [ ] Payment error shows a clear message, not an HTTP code
- [ ] Works on mobile (viewport 375px+)

### Integration
- Use the existing Button component from /ui/Button
- Follow the state pattern from /hooks/useAsync
- Tests with Vitest, minimum 80% coverage

That is a sufficient specification for SDD. Not 100 pages. It's 20 lines that make explicit the decisions the team had already made mentally but hadn't written down. The difference is that now an AI agent can read them and generate code that respects those constraints.

The three levels of formality

• Level 1 - Structured prose: Markdown with clear sections (problem, constraints, criteria). Enough for 80% of an MVP's features. 10-15 minutes of writing.
• Level 2 - API contracts: OpenAPI for endpoints, JSON schemas for data models. Needed when there are multiple consumers (mobile, web, agents). 30-60 minutes.
• Level 3 - Formal behavior: Gherkin for critical flows, state machines for complex workflows. Reserved for business logic where an error has financial or regulatory impact. 1-2 hours.

Rule of thumb: If an AI agent would need more than 2 rounds of correction to generate the right code, the feature needs a specification. If it comes out right on the first try with a prompt, it doesn't.

Case study: from 7 sprints to 3 sprints with SDD + Claude Code

Context: B2B SaaS, team of 6 developers, product in a post-MVP growth phase. They were rebuilding the billing module to support multiple currencies and European tax compliance.

Without SDD (original estimate): 7 sprints

• Sprint 1-2: Development of the billing core with Copilot (ad hoc prompts)
• Sprint 3: They discover the data model doesn't support multiple currencies correctly
• Sprint 4: Schema redesign + data migration
• Sprint 5-6: Partial reimplementation + tests
• Sprint 7: Integration, QA, hotfixes

Classic pattern: Sprints 3-4 are pure rework. The team didn't formally define the multi-currency constraints before starting. Copilot generated code that assumed a single currency because no prompt specified otherwise.

With SDD: 3 sprints

• Week before: 3 days writing specifications (multi-currency data model, tax rules per country, API contracts with OpenAPI, acceptance criteria in Gherkin for critical flows)
• Sprint 1: Claude Code generates the schema, the endpoints and the base tests from the specs. Human review: 70% of the code accepted without changes
• Sprint 2: Business logic and tax rules. The project's "constitution" (immutable rules) prevents the AI from generating shortcuts that violate compliance
• Sprint 3: Integration, QA, deploy. No redesigns because the critical decisions were documented from day 1

Matrix: when SDD is positive ROI vs overhead

SDD isn't always the right answer. There are contexts where the overhead of writing specifications doesn't pay off. This matrix helps you decide:

General rule: If the cost of an error exceeds 4 hours of rework, or if more than 2 parties (humans or agents) are going to work on the same feature, SDD is positive ROI. Below that threshold, a well-written prompt is enough.

Lightweight tools for writing specs

You don't need specialized software to practice SDD. The best specifications for MVPs are written with tools you already have:

1. Structured prose in Markdown

The most accessible format. A .md file with clear sections: problem, constraints, acceptance criteria, integration. It works with any AI agent (Claude Code, Copilot, Cursor) because it's plain text that gets included as context.

When to use it: For 80% of an MVP's features. It's fast to write (10-15 minutes) and formal enough for an agent to generate consistent code.

2. OpenAPI for API contracts

If your MVP has an API (and almost all of them do), an OpenAPI specification is the contract that connects frontend, backend and any AI agent that consumes or generates endpoints. Modern agents interpret OpenAPI directly and generate code that respects the schema.

When to use it: When there are multiple consumers of your API (mobile app, web, third-party integrations) or when an AI agent is going to generate both the backend and the frontend.

3. Gherkin for critical flows

Gherkin (Given-When-Then) isn't just for testing. It's a format that describes expected behavior in a way both humans and AI understand without ambiguity. Ideal for flows where an error has real impact: payments, sign-up, permissions.

Feature: Checkout with multiple currencies

  Scenario: User completes purchase in EUR
    Given a user with a cart of 3 products
    And the selected currency is EUR
    When they confirm payment with Stripe
    Then the charge is processed in EUR
    And they receive email confirmation in under 30 seconds

  Scenario: Payment failure shows an understandable error
    Given a user at the confirmation step
    When the payment fails due to insufficient funds
    Then they see the message "Your bank declined the payment"
    And they do not see technical error codes

4. Project "constitution"

A short document (20-40 lines) that defines the project's immutable rules: architecture patterns, naming conventions, allowed dependencies, folder structure. This document is loaded as permanent context in the AI agent (what the discipline of context engineering calls "curated context"), ensuring all generated code respects the team's standards.

Example tools: CLAUDE.md for Claude Code, .github/copilot-instructions.md for Copilot, .cursorrules for Cursor. The format varies, the function is the same.

5. onext SDD Accelerator

An accelerator developed by onext (on open standards, no lock-in) that integrates SDD directly into the team's workflow. It generates specification templates tailored to the project's stack, validates that AI-generated code meets the constraints defined in the spec, and keeps the project's "constitution" in sync with the agent. Designed for teams that use Claude Code, Copilot or Cursor as their primary agents.

The "Quick Ship" bias and how to neutralize it

The Quick Ship bias is a cognitive trap: teams prioritize perceived speed (lines of code written, "finished" features) over real speed (features that work correctly in production without subsequent rework).

With the arrival of agentic AI, this bias intensifies. An agent can generate thousands of lines of code in minutes. The temptation to "we'll fix it later" is greater than ever. But the cost of fixing it later is also greater, because the agent has built layer upon layer of incorrect assumptions.

Three signs your MVP suffers from the Quick Ship bias

1. AI-generated pull requests require more than 2 rounds of review. If the agent doesn't understand the context, it generates code that needs constant correction. That's not speed, it's rework in disguise.
2. Different developers implement the same logic in different ways. Without a shared specification, each person (and each agent) makes different design decisions. The result is an inconsistent codebase that becomes exponentially harder to maintain.
3. The team discovers "surprises" during integration. The frontend expected one data format. The backend returns another. The API assumed token authentication, mobile expected cookies. Every surprise is an undocumented decision.

SDD isn't waterfall. It's minimal discipline.

Thoughtworks, in its SDD analysis for the Technology Radar, warns of a real risk: that teams confuse SDD with a return to big design up front. It's a valid concern.

"Within emerging practices like spec-driven development, we've noticed the risk of reverting to classic software engineering antipatterns, especially a bias toward heavy up-front specification and big-bang releases."

— Thoughtworks, Technology Radar Vol. 33

The answer lies in proportionality. A 20-line spec for an MVP feature isn't waterfall. It's the same discipline we apply when we write a test before coding (TDD). Nobody argues that writing tests is "overhead" incompatible with agility. Specifications for AI are the equivalent: documenting intent before executing.

The goal isn't to document everything. It's to document enough that the critical decisions don't stay in one person's head (or worse, in an LLM's statistical inference).

How to get started with SDD on your next MVP

You don't need to adopt SDD in full to see results. These are the steps to get started:

Step 1: Identify the MVP's 3-5 critical decisions

Before writing code, list the decisions that, if made poorly, will generate the most rework. Usually they are: data model, API contracts, critical user flows, and technical constraints (compliance, performance, integrations).

Step 2: Write a lightweight spec for each one

Use structured prose in Markdown. 15-20 lines per spec. Include: problem, constraints, acceptance criteria, integration with existing code. Total time: 2-4 hours for a typical MVP.

Step 3: Create the project "constitution"

A file with the immutable rules: architecture patterns, naming conventions, allowed dependencies. This file gets loaded as context in your AI agent. Time: 1-2 hours, one time only.

Step 4: Use the specs as input for the agent

Instead of writing ad hoc prompts, reference the spec when you ask Claude Code or Copilot to generate code. The agent produces code that respects the documented constraints.

Step 5: Review against the spec, not just against the code

In code review, the first question isn't "is the code well written". It's "does the code meet the specification". If there's no spec, that's the first problem to solve.

Total investment: 1-2 days of specification before you start coding. Typical return: 3-5 weeks of rework avoided. Conservative ROI: 10-15x on the time invested.

Conclusion: real speed isn't measured in lines of code

The Quick Ship bias has taught us to measure speed in features shipped, lines written, sprints completed. But the speed that matters is a different one: how long it takes for a feature to work correctly in production, without subsequent rework, and to stay stable over time.

SDD doesn't slow delivery down. It eliminates the destructive iterations that slow it down. Teams that adopt it don't write less code. They write the right code sooner, and avoid writing the same code three times.

In a world where AI agents can generate thousands of lines in minutes, the most valuable skill is no longer coding fast. It's specifying precisely what needs to be built. That's Spec-Driven Development. And that's what separates the teams that deliver from the teams that rework.

2 days of specifications avoid 5 weeks of rework. The numbers speak for themselves.

Written by

Jordi García

Tech Lead at onext

Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.

LinkedIn →