Write the spec. Then try to kill it.
I spec'd an entire SaaS before writing a line of code. Then I asked AI to kill it. Here's the workflow that came out the other side.
I’ve been building a side project, a browser-based prototyping tool for designers (name TBD, the one I had was taken). Before touching any code, I spent a week doing nothing but writing a spec. Brain dumps into Claude until I had a single markdown file that could answer any “how does this work” question before implementation started.
I had a solid plan. And then it completely got away from me.
What over-speccing looks like
By revision 2, the spec had:
| Feature | What I told myself |
|---|---|
| Multi-role permission matrix | ”I should model every user type up front” |
| Semantic retrieval pipeline with embeddings | ”Keyword lookup won’t be enough” |
| Gated launch flow | ”I need to control adoption from day one” |
| Detailed onboarding event logging | ”I need full funnel data before shipping” |
| Custom runtime caching strategy | ”Performance architecture needs to be settled now” |
| Compliance readiness notes | ”Larger customers will ask for this eventually” |
| Key management architecture decision | ”Security choices have to be perfect before v1” |
I was building for a company I didn’t have, with customers who hadn’t asked for anything yet.
I ended up trimming more than half the scope of my original spec. Roles collapsed, the waitlist became “just ship it,” onboarding logs became “use basic product analytics.”
But revision rounds weren’t what fixed the spec.
The pre-mortem fixed it
A pre-mortem is a planning technique where you assume failure upfront and work backwards to find the cracks. Instead of asking “will this work?”, you ask “it already failed, so what killed it?” This helps surface hidden assumptions before they cost you real time.
Before writing a line of code, I ran the finished spec through a single prompt:
It’s 18 months from now. This project shipped, got early users, and quietly died. What killed it?
Five causes of death came back. Three I could test before building anything:
| Cause of death | What it actually meant |
|---|---|
| Output quality looked good but failed real checks | Run evaluation tests before building. If quality is core to the product, it cannot sit in a v2 backlog. |
| First-load performance broke the core experience | The runtime choice was made before testing startup behavior. If speed is part of the value, test cold-start and warm-up early. |
| Bring-your-own-key created enterprise friction | ”Users can add their own API key” sounds simple, but procurement and security review can stall adoption. |
Two required spec changes:
| Cause of death | The design problem it exposed |
|---|---|
| One champion became the permanent support path | Setup depended on one person. There was no versioning model and no co-ownership plan. The architecture baked in a support bottleneck. |
| Prompt-only workflows stalled at visual refinement | Small UI changes took multiple prompt cycles. The spec needed a clear position on direct manipulation (point-and-click edits) before launch. |
The workflow
This is the part worth stealing:
1. Brain dump the idea — no structure, just everything in your head
2. Ask Claude to turn it into a spec
3. Revise the spec until the feature list feels right
4. Run the pre-mortem: "It's 18 months from now. This died. What killed it?"
5. For every predicted failure: is this testable before building?
6. For each testable risk, run a small prototype. Use what you learn to close open questions, then update the spec.
7. Now write code.The key constraint: assume you’re the only user. Not a company, not paying clients, just you and whoever stumbles onto the repo. Every feature that only makes sense at scale gets cut.
The pre-mortem does something revision rounds can’t. It forces you to argue against your own assumptions. You built the spec in optimist mode and the pre-mortem runs it in pessimist mode. The diff between those two is your real v1 scope.
What changed in the spec
| Before | After | |
|---|---|---|
| Users | Multi-role permission model from day one | Start with a single-user flow, expand later |
| Knowledge input | Retrieval pipeline plus embeddings | Plain text config injected into prompts |
| Launch | Gated release plan | Publish and learn from real usage |
| Analytics | Custom event instrumentation | Off-the-shelf analytics, minimal setup |
| Runtime | Complex runtime chosen upfront | Use the simplest runtime, spike alternatives |
| Auth | Workspace and org model | Basic sign-in that supports day-one needs |
| Security | Open questions across multiple options | One clear baseline with managed secrets |
| Monetization | Revenue model implied in v1 | No monetization in stage one |
The second spec is about half the length. Every decision has a rationale. There are no open questions blocking implementation.
The project isn’t shipped yet, but for the first time I know exactly what I’m building and why each decision was made. A tighter spec was the outcome.
The pre-mortem is the step my previous project specs were lacking, and it’s a point in my workflow I will continue to experiment with. Try it out! It might help refine your plans.
Further reading
On spec-driven development with AI:
- Spec-Driven LLM Development (SDLD) — David Lapsley’s writeup on treating specs as contracts between humans and AI agents
- Spec-driven development: unpacking the practice — Thoughtworks on why vibe coding fails and what SDD replaces it with
- GitHub Spec Kit — open source toolkit for spec-driven workflows with Copilot, Claude Code, and Gemini
On the pre-mortem:
- The Pre-Mortem Method — Gary Klein writing on Psychology Today, free to read
- Pre-mortem — Wikipedia’s summary of the technique and the “prospective hindsight” research it grew from