The most expensive mistake a non-engineer founder can make with an AI idea is to skip validation and go straight to a prompt. Writing prompts feels like progress. It is implementation against an untested hypothesis. The hypothesis to test first is not “will users want this?” It is the harder question: can the model actually do this reliably enough to be worth shipping? Get that wrong and every Cursor session, every Bolt build, every Lovable iteration is a sunk-cost machine pointed the wrong way.
This article walks through a seven-step validation procedure a non-engineer can run in under a week with no code and no production prompt. It is the front end of the idea-validation playbook and the first chapter of the broader idea-to-product manifesto. Done properly, the PRD writes itself.
Decision Scope
This is an editorial validation framework, not legal, financial, or technical advice. Treat the numbers, rubrics, and thresholds as planning heuristics. Validate against your own domain, users, and the current frontier-model leaderboard before acting.
Why AI ideas validate differently from SaaS ideas
The Lean Startup template — customer-discovery interviews, problem-solution fit, MVP-then-iterate — was designed for an era when the binding question was demand. Technical risk was modest because the tech was deterministic.
AI ideas invert that calculus. Plenty of people want a tool that drafts legal contracts or summarizes team calls. The hard part is: can the model draft a contract a lawyer will sign? Summarize a call accurately enough that a sales manager will trust it without listening to the recording?
In 2026, demand for AI products is enormous and largely uncontested. The capability ceiling decides whether your idea ships. That ceiling is set by current frontier models — Claude Opus 4.8, GPT-5, Gemini 2.5 Pro, Llama 3.3 — and by how reliably they perform your task on your users’ inputs, at a cost you can charge for. We check demand in step five, but treating demand as the constraint is how SaaS-era founders waste two quarters before realizing the model cannot do the thing.
Step 1: Restate the idea in one sentence
Write the idea as a single falsifiable sentence:
My AI does X for Y users when Z.
X is the specific task, Y the specific user, Z the trigger.
Well-restated: “My AI drafts a first-pass NDA for a solo founder when they paste the other party’s term sheet.” Poorly restated: “My AI helps lawyers.” (X, Y, Z all missing.) “My AI is a Notion competitor with AI features.” (Not an AI idea — a SaaS idea with AI marketing.)
If you cannot write the sentence, you do not have a product. You have a feeling. The rest of the steps will not work until the sentence exists.
Step 2: Identify the AI capability it depends on
Most ideas reduce to one of five primitives:
| Capability | Example tasks |
|---|---|
| Classification | Triage email by urgency. Flag a clause as high-risk. |
| Extraction | Extract party names and dates from a contract. |
| Generation | Draft an NDA. Write a customer reply. |
| Planning | Book a meeting across three calendars. |
| Multi-turn dialog | Coach a salesperson live during a call. |
The frontier is uneven. As of June 2026, frontier models are excellent at classification on short clean inputs, good at extraction when the schema is small, mixed at generation (fluent on the surface; factual reliability depends on grounding), inconsistent at planning beyond five steps, and weakest at long multi-turn dialog with strict state. Naming the capability tells you which part of the frontier you are betting on. If your idea spans two, name both and order them.
Step 3: Sanity-check against current SOTA
This is the step almost no founder runs, and the one that decides whether the next twelve weeks will succeed. Open a chat console with each of the three frontier providers — Claude Opus 4.8 at claude.ai, GPT-5 at chatgpt.com, Gemini 2.5 Pro at gemini.google.com. Paste three to five realistic inputs from your product’s domain — real document length, real jargon, real messiness. Do not paste a toy example. Ask the model to do the task. Read the output as the end user. One question: would they accept it as a starting point, or throw it away?
Three outcomes:
- All three do the task well. Capability is above your bar. Continue — remaining risk is workflow and unit economics.
- One or two of three do it well. Capability is at your bar. Continue with a tighter rubric and a noted model choice.
- All three do it poorly. Capability is below your bar. Stop. Reduce X, change Y, or shelve until the frontier catches up.
Outcome three saves the most money. A six-week build to discover the model cannot do the task is a hundred-thousand-dollar mistake. A two-hour chat session that reveals the same fact is free. The leaderboard changes quarter by quarter — check the Artificial Analysis ranking and the Anthropic and OpenAI model cards before each new project. Do not validate against your memory of what models could do twelve months ago.
Step 4: Run a 10-prompt feasibility set with a rubric
Step three was vibes. Step four is structure. Build a feasibility set of ten realistic inputs across the distribution your real users will produce: three easy, four medium, three hard. Write a rubric for what a “good” output looks like before running any prompts — specific enough that a friend reading the rubric and an output could agree on the score (e.g., “Summary no longer than five sentences.” “Extracted names match the contract verbatim.”)
Run each input through the best-performing model from step three and score on a 0-1-2 scale:
| Score | Meaning |
|---|---|
| 0 | Unusable. User would discard or be misled. |
| 1 | Partially usable. User accepts as a starting point but heavily edits. |
| 2 | Fully usable. User accepts with light or no edits. |
Tally out of 20: 17–20 is well above your bar (proceed). 13–16 is at your bar (proceed with tighter scope or narrower user). 9–12 is below your bar (reduce X, change Y, or add retrieval or fine-tuning). 0–8 is far below — shelve or pivot.
Do not run the same input twice and average — run each once with your best honest prompt and accept the result. Save the prompts and outputs. They are the start of your eval suite, the artifact our editorial-600 sibling stop scoping AI projects in features, scope them in evaluations argues should be the basis of every AI engagement.
Step 5: Talk to 3 to 5 prospective users
Capability validation is necessary but not sufficient. A product the model can build is not a product users will pay for. Do not pitch. Do not show the prompts. Hear users describe the problem in their own words. Three questions:
- “Walk me through the last time you did [task X], starting from the moment you knew you had to do it.” Listen for inputs, tools, time, people — the workflow your product enters.
- “What was the worst part?” Listen for the friction your product is supposed to remove. If the worst part is something your product does not touch, you have a problem.
- “What would you pay to make that worst part disappear?” Listen for the unit-economics ceiling.
If three of five independently describe the same worst part, and your product removes it, you have demand signal that does not depend on a finished build.
Step 6: Decide — AI lift or wrapper?
This step separates AI products from SaaS products with an LLM call inside. Ask:
If we removed the AI and replaced it with a forty-dollar-an-hour human, would the rest of the product still be valuable?
Yes. You have a workflow product. The AI is a cost optimizer, not the value driver. The binding question is workflow design, integration depth, and adoption — not capability. The Lean Startup canon applies.
No. You have an AI product. The capability you validated in step four is doing the work, and the rest of the idea-to-product pipeline applies.
Honesty test: if the sentence from step one still makes sense with “an AI” replaced by “a contractor,” you have a workflow product. If it becomes nonsense — because of latency, scale, or unit economics — you have an AI product.
Step 7: Write the one-paragraph go/no-go memo
Compress everything into a memo:
Idea. [Sentence from step one.] Capability. [Word from step two.] Feasibility. [Score from step four plus one sentence on the model.] Demand. [Dominant pattern across user interviews.] AI lift or wrapper. [One sentence from step six.] Decision. [Go or no-go, plus one-sentence rationale.]
The memo earns the right to write a PRD. Founders who skip it produce PRDs that read like wish lists; founders who write it first produce PRDs that read like contracts, because every clause traces back to evidence. It is also the document you hand a build partner — a serious AI partner reads it, asks three follow-up questions, and uses it to scope the eval suite the engagement will be contracted against.
A worked example: a clause-extraction idea
A non-technical founder with a paralegal background has the idea: an AI that extracts indemnity, liability-cap, and IP-assignment clauses from vendor MSAs for in-house legal counsel.
- Step 1. “My AI extracts indemnity, liability-cap, and IP-assignment clauses from a vendor MSA for an in-house legal counsel when the contract PDF is uploaded.”
- Step 2. Extraction plus downstream classification (high-medium-low risk per clause).
- Step 3. Five anonymized MSAs pasted into Claude Opus 4.8, GPT-5, and Gemini 2.5 Pro. All three locate the clauses reliably; two reproduce verbatim text, one paraphrases. Proceed.
- Step 4. Ten anonymized MSAs (three easy, four medium, three hard). Rubric: extracted text verbatim, all three clause types present, risk label matches the founder’s own attorney-trained label. Score: 17 of 20. The three lost points were paraphrase-not-quote — a prompt fix, not a capability problem.
- Step 5. Five in-house counsel interviewed. Four independently name the same worst part: around forty minutes per contract locating the three clauses. Three name a price they would pay.
- Step 6. A paralegal costs around twenty-five dollars per contract; the AI around twelve cents. The AI does real work, but workflow integration into the counsel’s review loop is where most buyer-side value lives. Verdict: AI product with workflow elements.
- Step 7. The memo:
Idea. AI that extracts indemnity, liability-cap, and IP-assignment clauses from a vendor MSA for an in-house legal counsel when the contract PDF is uploaded. Capability. Extraction plus risk classification. Feasibility. 17 of 20 against Claude Opus 4.8 on ten realistic MSAs; lost points are prompt-fixable. Demand. Four of five in-house counsel named clause-location as their worst part; three named a price. AI lift or wrapper. AI product with workflow elements; the AI is necessary because of unit economics. Decision. Go. Next step: a PRD naming eval thresholds for extraction accuracy and clause-risk classification.
Four days of focused work, zero lines of code. The kind of artifact a build partner can scope a six-to-twelve-week MVP against, and the kind a seed investor reads in two minutes.
FAQ
How long does the full procedure take?
Three to seven days for a focused founder. Step one is thirty minutes; step three a half-day; step four one to two days; step five three to five short interviews; steps six and seven take an afternoon.
Do I need an engineer to run any of this?
No. A chat-console subscription with one frontier provider and a notebook for scoring is enough. No code, no API keys, no prompt-engineering frameworks.
Which frontier model should I use for the feasibility test?
Run step three against all three (Claude Opus 4.8, GPT-5, Gemini 2.5 Pro) and run step four against the best performer. The winner changes by capability and domain — do not assume your favorite model wins.
What if my idea spans multiple AI capabilities?
Name and order them in step two, then validate each independently. A chained task is only as reliable as its weakest link: if stage one scores 17 of 20 and stage two scores 11, the end-to-end ceiling is closer to the second.
What if I score 9 to 12 on the feasibility set?
You can still ship, but you need retrieval, fine-tuning, or a human-in-the-loop step, and build cost just went up. A 9-to-12 score is the most expensive zone — feasible enough to tempt, not reliable enough to ship cleanly.
Does this procedure apply to agentic ideas?
Yes, with one modification. For agentic ideas, step four must measure end-to-end task success across the full plan, not single-prompt quality. Score an input as 2 only if the plan completes with no human intervention. Most agentic ideas score lower on the same scale.
What is the most common reason ideas fail at step three?
The model cannot handle the input distribution at the length, messiness, or domain-specificity real users will produce. The frontier is excellent on clean inputs and degrades on long, messy, niche inputs. Most founders test the former and ship into the latter.
Can I skip this and build an MVP fast with Cursor or Lovable?
You can. The expected cost of skipping is six to twelve weeks pointed at the wrong capability bet. The cost of running the procedure is one week. The math is not close.
What deliverable justifies moving to a PRD?
The one-paragraph go/no-go memo from step seven. If you cannot write it, you are not ready for a PRD. If you can, the PRD writes itself in a day.
Next step
Validation is the gate, not the destination. Once the memo is written, the next chapter is the PRD, the architecture, and the eval suite to contract against. Sibling chapters cover what an AI MVP actually is and the AI feasibility check; the idea-to-product manifesto sets the program in context. If you have the memo and want a second opinion on whether to build, scope, or pivot, that is what our idea-review conversations are for.
Arthur Wandzel
