AI coding tools have made it very easy to start building. Open an editor, describe what you want, and within minutes there is a screen on the page. For a demo, that is wonderful. For a product that real people will depend on, it is usually the most expensive way to begin.
The reason is simple. A coding model builds exactly what you describe. If the description is vague, the model fills the gaps with guesses, and every guess is something you will pay to undo later. The faster the tool, the faster the wrong thing gets built.
So in my process, the spec comes before the code. Every time.
What goes wrong without one
When teams skip the spec, I tend to see the same pattern.
- The first version looks impressive, because the happy path works.
- Then someone asks about roles, permissions or what happens when data is missing, and the answer is "we have not thought about that yet."
- The model is asked to bolt those things on. Each fix touches code that was never designed for it.
- Scope keeps moving, because nothing was ever written down and agreed.
None of this is the model's fault. It is doing its job. The problem is that nobody did the thinking it depends on.
Step one: a requirements brief
Before any spec, I write a requirements brief. It pulls together everything from discovery in one place:
- transcripts from the calls and walk-throughs
- a step-by-step map of how the work is done today
- every spreadsheet, form and report currently in use
- the constraints and rules the product has to respect
- the one metric we agree the product should move
The brief is written in plain language. It is not a technical document. Its job is to make sure nothing important lives only in someone's head or inbox, and that the founder can read it and recognize their own problem.
Step two: deep research turns the brief into a spec
The brief then goes into Perplexity's deep research. What comes back is a detailed specification:
- users and roles
- core flows, step by step
- the data model
- integrations
- edge cases
- security
- acceptance criteria for every core flow
The important part is the sources. Every assumption about the market, the regulations or how similar products behave comes with a citation. That turns opinions into things we can check. If the spec says a regulator requires something, I can see where that came from.
Deep research is not a replacement for judgment. It is a very fast, very thorough first draft. I read every section, push back where it is wrong, and fill in what only the founder knows.
Step three: lock version one
Then we review the spec together and lock version one, before any design starts.
Locking does not mean nothing can change. It means changes become decisions instead of drift. If a new idea comes up, we write it down, weigh it against the deadline, and either update the spec on purpose or park it for version two.
When I work with an existing team, their tech lead reviews the spec against their architecture before it is locked, so it fits what they already run.
Why this makes AI coding faster
It sounds slower to write a spec first. In practice it is the opposite.
The model gets better instructions. A coding agent working from clear flows, a defined data model and acceptance criteria makes far fewer wrong guesses.
Rework drops. Most expensive rework comes from discovering a requirement after the code is written. A sourced spec surfaces those requirements up front.
Reviews get easier. When there are acceptance criteria, "is this done?" has an answer. Each preview can be checked against the spec instead of against someone's memory.
The spec stays useful. As decisions change during building and testing, the spec is updated, so it stays the source of truth. It becomes the document a new developer or an investor can read to understand the product.
Why this makes it cheaper
Time is the cost that matters most early on, and the spec saves it in the places that hurt.
A day spent on the spec can save weeks of rebuilding features that were designed without the full picture. It also keeps the AI tools pointed at work that will survive, instead of generating code that gets thrown away.
A coding model builds exactly what you describe. The spec is how you make sure you are describing the right thing.
What the spec does not do
A spec is not a guarantee. Real users will still surprise you, which is why every preview gets tested with them, and why the spec keeps changing as testing teaches us things. The point is not to predict everything. The point is to start building from what we know, with sources behind it, instead of from guesses.
How I use this on my own products
My own products follow the same order. BlastRocket started as a written specification before it became software, and its documented decisions, like failing closed when evidence is missing, came out of that thinking rather than out of the code.
If you have an idea and are tempted to open an editor and start prompting, email me first. A short conversation about what the spec needs to cover can save you a lot of rebuilding later.