2.1.1 - The Only Path Your Prototype Actually Needs to Walk

Define the prototype path: say what the prototype is meant to teach, which path will test it and what signal counts as proof.

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.

Sharpen the prototype path with AI

This is a Build idea, so there are two AI moves: first Sharpen the prototype path using the prompt below, then Build it with AI, vibeCoding the thinnest working code that tests the decision.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real prototype path and keep the instruction exactly as visible here. It helps you put your build/prototype-path.md together by refining your three lines until two people would make the same product decision from them.

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.

Example of the standard:
Vague: "Test whether people like the check-in email."
Sharp: "Learning goal: whether a solo operator acts on a check-in email instead of ignoring it. Test path: they add three real subscriptions, get one email listing them and click through to mark one for cancel. Proof signal: at least one is marked within 24 hours."
The sharp version is specific enough that two people would build the same test. The vague one is not.

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 that two people would build the same thin test. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what the prototype teaches, which path tests it and what signal counts as proof?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it

Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it.

There are six ways to work with AI across a build. This idea's AI moves are noted above. See Working with AI for all six and where each fits.

The same idea on a recipe card

Before cooking a new dish for a dinner party you make one small test portion. You do not cook the whole five-course meal just to find out whether the sauce works. One trial spoonful answers the only question that matters right now, and it costs you almost nothing if it fails.

Your prototype path is that test portion. Build the thinnest version that answers your one question, not a small version of the whole product. Name the question, the single path that tests it and the sign it passed, the way one taste of the sauce tells you whether to cook the full batch.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

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.

A prototype only needs one path, the thin line from start to the single thing it is meant to teach you. Every tempting side route gets cut, because the prototype exists to answer one question, not to be the product.

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.

What you'll walk away with

This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own knowledge-base/build/prototype-path.md written and sharpened: the prototype path pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call.

Write it down

Your prototype-path.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/shape-build-launch/build/prototype-path.md is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

The .md ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code.

Writing it down is how you keep good context for your AI. See Keep the signal, not the noise for why this matters across a whole build.

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.

How to document your prototype path

Write your prototype path up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# Prototype path

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

## Evidence
Why you believe this. Conversations, examples, tickets, your own experience.

## Decision
What you are optimising for and what you are saying no to.

## Risk
Where you might be wrong and what would tell you.

## AI instruction
The standing note your AI reads on this project.

Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier.

## Answer
Learning goal: Whether the sauce works
Test path: Make one small test portion, not the whole meal
Proof signal: The trial spoonful tastes right

## Evidence
Every time I have committed a full batch to an untested sauce I have wasted it, so a small trial first pays off.

## Decision
Optimising for learning whether the sauce works. Saying no to cooking the whole meal before I know.

## Risk
A tiny portion might not behave like the full pan. Make it big enough to taste properly, small enough to throw away.

## AI instruction
The prototype is one small test portion to learn whether the sauce works. Do not scale up to the full meal until the trial spoonful tastes right.

Common questions

I have researched three stacks and still have nothing built. Why?
Because comparing options feels like progress without being it. Pick one path and build it this week, the point of All the research, nothing to show for it.
Shouldn’t a prototype show off everything the product will do?
No. One real path walked end to end teaches you more than ten half-built ones. Build the path where the user first gets value.
Which path do I pick first?
The single journey the product exists for. If it does not work, nothing else matters. If it does, you have something to build on.
Won't building just one path mean rework later?
Less than building five and learning nothing. One clear path tells you what is worth building next.

What now?

Apply it. Guide me turns what you are building into a prompt that walks you through this idea.

Get all 27. The guide is a free coffee-length read with the whole method. Join free and it is yours to download.

Get a hand. Work with me and we will work out together what is worth doing. The first conversation is free.