Something changed in how people build software, and it happened fast.
AWS shipped Kiro in July 2025 – the launch coverage called it a specification-driven IDE. GitHub open-sourced Spec Kit that September. Ethan Mollick wrote that the skill worth having with these tools is "specs, not tricks" – that the edge is no longer clever prompting but writing down, precisely, what you actually want built. The phrase going around is spec-driven development, and the claim underneath it is simple: the specification, not the code, is the real artifact. The code is now the cheap part. The expensive part – the part that decides whether the thing is worth building at all – is the document that says what to build and why.
I read all of this with a strange feeling, because it's the exact premise I've been building a product on from the start – and I hadn't heard the name. I came at it from the other end entirely: not from the coding tools, which assume you have already decided what to build, but from the question of whether the thing is worth building at all. Same conclusion, opposite door.
The verdict was never the point.
Touchstone gives founders an honest read on an idea – Go, Conditional Go, or No-Go, scored across six dimensions. That's the part people notice, because a verdict is a satisfying thing to receive.
But the verdict was never the point. Every validation also produces a build-ready document suite: a product requirements doc, a build guide, brand guidelines, a marketing plan, a business case, a build checklist, an activity tracker. Not a slide deck. Not a scoring breakdown with some encouragement stapled to it. A specification a developer can open and start building from the same day.
From the start it was the unglamorous half of the product – harder to explain than the verdict, easier to overlook. This year the industry decided it was the whole game.
A report tells you something. A spec lets you do something.
Most tools in this space hand you a report. A market-size estimate, a competitor grid, a paragraph of feedback, a number. That's information, and information is where founders get stuck – because knowing your idea scores a 7 doesn't tell you what to build on Monday.
A specification is different in kind, not degree. It's the bridge from "this is worth doing" to "here's the thing, start here." The reason spec-driven development caught on is that people finally felt the gap between the two: an AI can write the code in an afternoon, but only once someone has done the harder work of specifying what the code is supposed to be. That harder work is the artifact. It always was.
The part the wave doesn't mention.
There's a catch the industry conversation skips, and it's the part I care about most.
A spec is only worth having if the judgment behind it is honest. It's easy to generate a beautiful specification for a bad idea – the AI will happily write you a flawless build guide for something nobody will buy. A spec built on a verdict that was quietly nudged toward "yes" is worse than no spec at all, because it sends you off to build the wrong thing with confidence.
So the suite includes the one document most tools won't produce: the No-Go. The willingness to tell a founder the honest answer is don't build this – and to mean it even when "build it" would be the more profitable answer for me to give. The most trusted tool wins, not the most flattering one. The spec is the deliverable. The honesty is what makes it safe to act on.
"The spec is the deliverable. The honesty is what makes it safe to act on."
Trusting the discipline.
When I started, I didn't have a name for what I was doing. I had a method – write the thing down before you build it, and be honest about what the writing reveals – and I trusted it further than I could see. It turns out the method now has a name, a GitHub repo, and a category. The industry arrived at document-driven development the same way I did: by discovering the document was the point.
If the spec is the asset, the only question left is whether yours is built on a verdict you can actually trust.
That's the tool I built. The verdict's free. usetouchstone.ai
Want more like this? Rick writes about the go/no-go decision, founder counterintuitions, and the business of building ventures worth building.
All writing