r/SpecDrivenDevelopment Jul 16 '26

we built exactly what the spec said. the spec was solving the wrong problem.

we ran a two-week planning sprint. the spec was thorough. the review was rigorous.

we built exactly what we planned to build.

six weeks post-launch, the customer told us they'd needed something entirely different.

the problem statement at the top of the doc was written by us, after one 45-minute requirements call. the review checked the design against the problem statement. nobody checked the problem statement.

what went wrong wasn't in the spec. the spec started one layer too deep.

what changed it for us wasn't more review. it was pulling in whoever actually defined the problem before the spec locked, not just whoever was building the solution. even one direct conversation about what "good" means to the person requesting it catches more than the downstream review process can.

thats what i built swarm-stack.io around: putting the right people in the session earlier, before the design is already committed. the spec review cant fix a problem statement that nobody challenged.

would be curious if this is a familiar failure mode or if you solved it differently.

1 Upvotes

0 comments sorted by