Spec Debt vs Tech Debt

We keep blaming “tech debt” for slow delivery.

SDD made a big entry in 2025; but a lot of what hurts velocity isn’t code—it’s spec debt.

Spec debt = ambiguity, contradictions, and missing decisions in the PRD/one-pager that ripple into design, estimates, and code. It compounds just like tech debt—only earlier and nastier.

Symptoms you’re calling tech debt but aren’t:

  • Engineers “blocked” waiting on copy, edge cases, or API shapes.
  • Designs reworked because constraints surfaced late.
  • QA finding “bugs” that are actually unmade decisions.
  • Analytics can’t measure success because metrics weren’t specified.

The hidden cost: every unclear line in a spec becomes 3x rework later—design tweaks, code churn, test rewrites, launch delays.

Antidote: Spec QA (5 minutes, zero ceremony)
Before any ticket leaves “Define,” run this checklist:

  1. Problem & Outcome – What user behavior must change? What metric moves?
  2. Scope Boundaries – What’s explicitly out? (Name one thing you’ll say no to.)
  3. Interfaces & Contracts – Events, API shape, states, empty/error cases.
  4. Constraints – Perf, security, legal, platform limits; acceptable tradeoffs.
  5. Telemetry – What to log, how we’ll know it worked; guardrail metrics.
  6. UX Acceptance – Screens, copy, and the “good enough” criteria.
  7. Rollback – Pre-agreed revert conditions and kill switch owner.

Workflow tweak that pays off:

  • PM/Designer drafts the spec → Spec QA huddle (15 min) with EM + 1 Eng → estimates.
  • Anything failing the checklist returns to “Define,” not “In progress.”

What you’ll notice in 2 sprints:

  • Fewer “quick clarifications.”
  • Cleaner PRs, smaller diffs.
  • QA writing tests against intent, not vibes.
  • “Tech debt” tickets shrink because the code finally had a clear contract.

Call it what it is: most “tech debt” starts life as spec debt. Fix the spec; the code will thank you.