I asked an AI for a build plan. It answered two of my twelve questions — both by accident.

The step nobody audits

The argument for planning first is sound, and most of what is on this site argues it: a build plan is not a list of features, it is a graph of what depends on what. What changed in the last year is who writes it. The founder used to. Now the agent offers, and the offer is very good-looking.

That is the whole problem. A plan is judged by reading it, and these plans read well.

A build-ready plan is one where the next person — or the next agent — can start without asking you anything.

That definition is the only one that matters, because it is the only one that can fail visibly. Everything below is a way of testing it.

What I actually ran

One product idea. One prompt, written the way a founder writes it rather than the way a prompt engineer would. One model. One rubric, fixed in advance.

The idea

A small SaaS for freelance designers: upload a deliverable, send the client a link, the client comments directly on the image without creating an account, everything versioned. It is deliberately ordinary — a real shape of product, not a trick question. I constructed it for this test rather than using a client's, and nothing about the result depends on the idea being clever.

The prompt, verbatim

This matters more than the idea. A prompt written by somebody who studies prompts is not the prompt this gets in real life.

I want to build a small SaaS for freelance designers. The
problem is client feedback — right now it's scattered across
email, WhatsApp and Figma comments, and by the third round
nobody knows which version the client is even looking at.
 
The idea: the designer uploads a deliverable, gets a link,
sends it to the client. The client opens it and leaves
comments directly on the image without signing up for
anything. The designer sees everything in one place, version
by version.
 
I'm a solo founder and I'll be building it myself with an AI
coding agent. Stack is Next.js and Postgres unless you think
otherwise.
 
Give me a build plan I can start from.

The rubric

I did not write a rubric for this article. I used the one already sitting on this site: the Clarity Diagnostic, twelve questions across five dimensions — positioning, MVP boundary, feature logic, flows and dependencies, build readiness. It was published well before this test existed, which is the only reason its verdict is worth anything here.

Its eleventh question, written long before this test, reads: “If you handed this to a developer or an AI agent tomorrow, what would they ask first?”

The scoring rule

Presence, not taste. For each question: does the plan contain the answer? Three outcomes — answered, restated (it repeats what I told it without deciding anything), absent. That rule is why you can check my work instead of trusting it.

The result

The plan came back at 525 words: a recommended stack, ten features, a data model, a build order, technical considerations, success metrics, a timeline and a risks section. By the standards of a document, it is good — coherent, specific, and ordered.

Two answered. Three restated. Seven absent.

Before the interesting part, the fair part: the plan was genuinely useful in ways the rubric does not measure. The data model was sound. The advice to store normalised coordinates rather than pixels is the kind of thing that costs you a week if you learn it late. Flagging that clients open review links on phones was correct and load-bearing. None of that is nothing, and a founder who ignored it would be worse off.

But none of it is a plan. It is expertise, arriving as prose.

Why those two, and not two others

Here is the part I did not expect, and the reason this is worth writing down.

Look at which two questions were answered. How many features are in v1 — ten. What has to be built before anything else — authentication, because it sits first in the build order.

Now look at the seven that were absent. What to cut. What the minimum is. Why a feature exists. What ranks above what. What breaks what. What an agent would ask. Where the decisions live. Every one of them requires that a judgement was made and recorded. Not retrieved — made.

That is the split, and it is not random. A language model is extremely good at producing the shape of a build plan, because the shape is the most predictable thing about it: stack, features, data model, order, risks, timeline. Fill that shape well and you get a document that reads like a plan and carries, for free, exactly the two facts a shape carries. The rest was never in the shape to begin with.

The seven, and what each one costs later

Missing answers are abstract until you price them.

• No cut line. All ten features were labelled “v1”. A v1 that includes billing, version comparison and batched email notifications is not a v1, it is a product — and what actually deserves to ship is the one decision nobody can make for you.
• No minimum. Without a definition of worth shipping, there is no way to know when you are done, so you are done when you are tired.
• No reason per feature. Version comparison is item nine. Nothing says why. When week five is tight, you have no basis for dropping it other than mood.
• No ranking. You cannot remove the third most important feature if nothing is first, second or third.
• No impact map. The plan never says that changing how versions work changes review links, comment anchoring and the comparison view at once. That is the graph, and it is the whole reason a plan exists.
• No anticipated questions. Ask an agent to build the review page from this and it must invent answers: is it server-rendered, do comments update live, what happens to comments when a version is deleted. It will invent them, and it will not tell you it did.
• No decision record. The plan is a chat message. Close the tab and the reasoning is gone — so the next session re-decides, differently.

The last one is the quiet killer. An agent needs somewhere to read the decisions from, and a conversation is not that place. This is also why features are not pages matters here: the plan named three screens in passing and never wrote the path a new user walks before getting anything, which is the artefact the build actually consumes.

When an AI-written plan is enough

Often, and I want to be precise about it rather than generous.

• A prototype you intend to throw away. No cut line is needed if nothing ships.
• A single-screen tool. With one screen there is no flow to map and almost no graph to hold.
• A feature inside a product that already exists. The boundary, the positioning and the dependency structure are already decided; you are asking about implementation, which is the part the model is genuinely strong at.
• The technical half of any plan. Stack, schema, sequencing, known pitfalls — take it. That advice was good.

The failure is specific: it appears the moment a plan has to carry a decision somebody has to own. Which is exactly the moment a new product begins.

Run it against yours

This costs ten minutes and does not require me. Take the plan you already have — from plan mode, from a chat, from your own head — and ask it the twelve questions. Not is it good. Just: is the answer in there, or would you have to supply it.

If a question makes you scroll back and look, that is a real answer. If it makes you think, the plan does not contain it — you do, and the agent cannot read you. Turning that gap into a plan is the actual work, and it is the part that has not been automated.

What I am not claiming

This is one plan, from one model, on one idea, on one day. It is not a benchmark and I have not ranked anybody. A different idea, a longer prompt or a second round of questions would produce a different document, and probably a better one — the model will answer most of these twelve if you ask it each of them directly. That is rather the point: the questions do the work, not the generator.

I also wrote the prompt, generated the plan, and scored it. That is three roles for one person and you should discount accordingly. The mitigation is the scoring rule: presence, not quality. Every verdict above can be checked against the plan by anyone who disagrees, and the two answered questions are answered on the page.

What I am claiming is narrower and, I think, durable. The industry adopted plan first and skipped the acceptance test. The generated plan reliably contains what its own format supplies, and reliably lacks what a decision supplies. Knowing which half you are holding is the whole skill, and it takes twelve questions.

Appendix: the plan in full

Reproduced complete, so the twelve verdicts above can be checked rather than trusted. The wording is untouched; only the formatting has been converted to this page's styles.

Product summary

“A lightweight review tool where designers upload deliverables and clients comment directly on the work — no client account required. Versioned, so everyone knows which round they're discussing.”

Recommended stack

“Next.js 15 (App Router) + Postgres via Supabase + Vercel + UploadThing or S3 for files + Resend for email. Supabase gives you auth, storage and row-level security in one, which matters when you're solo.”

Core features (v1)

• Designer accounts — email/password plus Google OAuth, via Supabase Auth.
• Project workspace — a project holds a client name and all its versions.
• Upload and versioning — drag-and-drop; each upload creates version N+1. PNG, JPG, PDF. Store originals, generate web-optimised previews.
• Shareable review links — a signed, unguessable URL per version. Optional passcode, optional expiry.
• Pin-based commenting — click anywhere to drop a pin. Threaded replies, anchored to normalised coordinates so they survive zoom and resize.
• Client identity without accounts — ask for a name on first comment, remember it in localStorage and a cookie.
• Comment resolution — designer marks resolved; filter open and resolved.
• Notifications — email the designer on new comments, batched in a fifteen-minute window; email the client on a new version.
• Version comparison — side-by-side or slider, between any two versions.
• Billing — Stripe. Free tier of one active project, Pro at twelve dollars a month for unlimited.

Data model

users        id, email, name, stripe_customer_id, plan, created_at
projects     id, user_id, client_name, title, created_at, archived_at
versions     id, project_id, number, file_url, preview_url, mime, created_at
review_links id, version_id, token, passcode_hash, expires_at
comments     id, version_id, parent_id, author_name, body, x, y,
resolved_at, created_at

Suggested build order

Auth and dashboard shell · projects CRUD · upload pipeline and version records · review link generation and the public review page · pin commenting and threads · resolution and filtering · email notifications · version comparison · Stripe billing · polish, empty states, error handling.

Technical considerations

• Security — review tokens must be cryptographically random, thirty-two bytes. Rate-limit comment posting per IP.
• Storage costs — originals can be large; serve generated previews and keep originals cold.
• Coordinate anchoring — store normalised values between zero and one, not pixels.
• PDF handling — render page one as the preview; multi-page is a later concern.
• Mobile — clients will open links on phones, so the review page must work there first.

Success metrics, timeline, risks

Metrics: time from upload to first client comment, comments per project, free-to-Pro conversion, projects reaching version three or more. Timeline: seven weeks, in the order above. Risks: Figma already has commenting, so differentiate on the no-account client experience; email deliverability needs a warmed domain; storage costs scale with usage.

That is the whole document. Read it against the twelve questions yourself — the disagreement, if you have one, will be about two or three verdicts, not about the shape of the result.