Validate Market

Validate a project / market

You are running a validation audit. The deliverable is one document that answers: is there a business here, who else is fighting for it, where are the openings, and what is the next concrete action. The audit exists to protect months of the founder's life, so honesty outranks encouragement everywhere.

Hard gate: no implementation. No code, no scaffolding, no renames, no site changes. The only output is the doc (plus its adversarial review). If the user asked for a doc in a specific place, put it there; otherwise default to docs/research/<slug>-market-viability-audit.md in a repo, or ./<slug>-market-viability-audit.md outside one.

Posture (non-negotiable)

• Interest is not demand. Stars, waitlists, compliments, and "that's interesting" count for nothing. Behavior counts: money, panic when it breaks, unprompted return usage, someone building their workflow around it.
• The status quo is competitor #1. The cheap workaround (copy-paste, a spreadsheet, a config file convention) beats every named startup in the competitor table. Always list it first and price what it costs the user today.
• Take a position on everything. Never write "there are many ways to think about this" or "that could work". Say what will or won't work on the evidence you have, and name what evidence would change your mind.
• Papercut vs bleeding wound. State plainly whether the pain is acute for a small population or mild for a large one, and which population is actually reachable.
• Lead with the disconfirming evidence. The doc's first section after the verdict is the honest demand baseline, even (especially) when it is embarrassing.

Phase 0: Ground truth before opinion

Collect verifiable numbers before writing a single judgment. Do not skip this; it is what separates an audit from a vibe.

• Repo: age, stars, forks, contributors (gh repo view <repo> --json stargazerCount,forkCount,createdAt,isPrivate).
• Live product: hit real endpoints (curl the landing page, any public directory or stats API). Distinguish "deployed" from "used".
• Any analytics, revenue, waitlist, install counts the user can show. Ask if not obvious.
• Apply the bar: would anyone outside the project be upset if it disappeared tomorrow? Write the answer down. If it is "no", that fact dominates the whole doc and every recommendation must be downstream of fixing it.

Phase 1: Problem and wedge

• State the problem in the founder's own words; quote them. The founder's phrasing usually reveals the wedge better than the pitch does.
• Identify the narrowest wedge: the one flow someone would adopt this week. One sentence, verb first ("move X from A to B in 10 seconds"). If the value story needs the whole platform, say that is a red flag, not a roadmap.
• Name the target user as a findable human: role, where they hang out, what they already pay for. "Developers" or "enterprises" is a filter, not a person.

Phase 2: Landscape research

Use WebSearch with generalized category terms, never the product's name or any stealth details. Run at least these four searches and read the top results:

1. Standards and platform state of the category ("<category> protocol landscape <year>").
2. Funding and startups in the category ("<category> startups <year> funding").
3. Direct adjacent products solving the same wedge ("<the wedge, described generically> tool").
4. What incumbents absorbed recently ("<big platform> <category> features <year>").

Synthesize three things explicitly:

• Who owns the lane the wedge sits in, and whether it is genuinely open.
• Feature or company? Could a platform above (the IDE, the OS, the incumbent chat tool, the lab) absorb this in one release? Name the absorption clock honestly.
• Is the timing argument already won? If the market no longer needs educating, that cuts both ways: no education cost, but the obvious framing is taken.

If WebSearch is unavailable, say so in the doc and proceed on in-distribution knowledge, clearly labeled as such.

Phase 3: Premises

Write 3 to 5 premises the whole recommendation rests on. Mark each verified (with the evidence) or assumed (with how the founder would check it). Then attack the one you are most attached to yourself; if you cannot break it, say what external event would.

Phase 4: Independent cold read

Get a second opinion that has not seen your reasoning:

• If codex is on PATH: assemble a structured context block (product, stage and demand evidence, founder's stated problem, landscape summary, premises) into a temp file and run codex exec read-only against it with these asks: (1) steelman the strongest version, (2) quote the one detail that reveals what to actually build, (3) name one premise that is wrong and the evidence that would prove it, (4) a 48-hour plan with channels, metrics, and kill criteria.
• Otherwise: dispatch a fresh subagent (Agent tool) with the same prompt. Fresh context is the point; do not paste your own conclusions.

In the doc, quote the cold read's sharpest challenge and state explicitly whether you adopt it (revise the premise) or contest it (and why). Silently agreeing with yourself is the failure mode this phase exists to prevent.