2.1.1 - The Only Path Your Prototype Needs

Prototype path

Is this the only prototype path users need?

The call

Build one path first. Otherwise AI helps you prototype everything at once and you learn nothing clearly.

Why it matters

The only path your prototype needs should stay explicit so users can understand what the prototype is proving. AI can generate many possibilities quickly, but human judgement decides which path protects the intended learning outcome. The difference is between focused evidence and scattered feedback from a drifting prototype.

Explainer

A prototype path is not a mini product. It is the thinnest route that can answer the question you actually have. Until you can name one learning goal, one path to test and one signal that would prove it, the prototype will keep growing. AI can help build quickly, but it cannot protect a prototype from drift.

Make the prototype path concrete

Compare the broad version with a version you can actually test.

• Too vague: The prototype should show the main search features.
• Concrete enough to test: The prototype only needs to show whether a content creator can enter a question, see results shaped by their saved context and act on one result without needing to understand how the context works.

The second version lets two people build the same thin test from it.

Check the prototype path

• Pass: You can say what the prototype is meant to teach, which path will test it and what signal counts as proof.
• Fail: If the prototype still sounds like a lighter version of the full product, the path is not tight enough yet.

Do not move into prototype build or polish work until this passes.

How to use AI for the prototype path

• AI chat: Rewrite the prototype path until you can state all three parts clearly.
• vibeCoding: Build the thinnest flow that tests this prototype path in practice before broader build work.
• AI-assisted coding: Carry the same prototype path into implementation and review so the live system keeps the same decision.

Sharpen the prototype path

Copy this prompt into AI chat, replace the bracketed lines with your real prototype path and keep the instruction exactly as visible here.

You are checking whether this prototype path is clear enough before you move forward.

Constraint:
The prototype path must be specific enough that two people would build the same thin test from it.

Working draft:
Learning goal: [what the prototype is meant to teach]
Test path: [which path will test it]
Proof signal: [what signal counts as proof]

Task:
Decide whether this prototype path is specific enough to guide the next decision. If it is vague, rewrite it so two people would make the same decision from this prototype path.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can say what the prototype is meant to teach, which path will test it and what signal counts as proof.

Return:
- A corrected prototype path
- A short explanation of what was vague

Evaluation

Before accepting the result, check whether two people would build the same thin test from it.

Example

To help you work through this, here is a real example. StartWithYourContext is an AI search tool built as part of the vibe2value project. Here is how its prototype path was written using the three parts:

• Learning goal: Does a content creator get more relevant results when their saved context shapes the search than when it does not?
• Test path: The user enters a question, sees results shaped by their context and decides whether to act on one.
• Proof signal: The user acts on a result in the same session instead of leaving to search elsewhere.

That prototype path is specific enough that two people would build the same thin test from it.

When there is more than one side

Not every product has a single prototype path. When a system serves more than one side, each side needs its own thin test or one side’s learning gets buried inside the other’s.

Multi-sided worked example

For example, StartWithYourContext has two different prototype paths:

• Content creator: Can they enter a question and get results that feel shaped by their existing content? The test is whether they act on a result.
• Developer: Can they clone the repo, follow the setup and have the full stack running locally? The test is whether they reach a working state without asking for help.

Both are valid prototype paths, but they test different questions. If only one is built, the other side’s learning is deferred by accident.

Risk and mitigation

• Risk: Expanding into multiple prototype paths too early, which dilutes learning and makes user feedback contradictory.
• Mitigation: Define one path-level success signal and reject new branches until that signal is stable.

Key takeaway

Do not move forward until you can say what the prototype is meant to teach, which path will test it and what signal counts as proof.

Work through this in a workshop

If your prototype path is still unclear, bring it to a free weekly workshop. Bring the messy part of your AI-assisted build and leave with a clearer next step. In some sessions, we walk through practical examples on the Cloudflare Workers stack to show how a rough idea turns into something that actually runs.

What do you think?

How are you deciding the one prototype path to keep and how is AI helping you protect that path while learning?