Kevin's insulated lunch bags were beautiful. He had spent most of a year on them: sourcing fabric, going back and forth with a manufacturer overseas, paying for a designer to get the zipper pulls just right. His first production run was two thousand bags, and it took a large share of his savings. They arrived in a shipping container and filled his garage.
Within a month he learned two things he could have learned in a weekend. Parents liked the bags but balked at the price, because the cheap ones at the grocery store were good enough for a seven-year-old. And the people who did love them, construction workers and nurses on long shifts, wanted a bigger bag than the one he had made. He had answered a question nobody asked, at full price, in production quality.
Kevin skipped the stage that would have saved him: the rough, cheap, slightly embarrassing version built only to find out whether he was right. That stage has a name, the low fidelity prototype, and it is the best bargain in starting a business.
A prototype is a question, not a product
Most founders hear "prototype" and picture an early version of the finished thing. That framing causes trouble, because it pushes you to make the prototype as good as possible, which makes it slow and expensive, which makes you reluctant to throw it away.
A more useful way to think about it: a prototype is a question you ask the world with something in your hands. "Will parents pay 30 dollars for a better lunch bag?" is a question. "Is a bag this size big enough for a twelve hour shift?" is a different question. Each one calls for a different prototype, and neither one requires two thousand finished bags.
When you start from the question, the prototype gets smaller. You only build enough to get an honest answer, and anything beyond that is cost without learning.
Why low resolution first
Resolution, or fidelity, is how close the prototype looks and feels to the real thing. A sketch on a napkin is low fidelity. A polished app with real data behind it is high fidelity. There are three good reasons to start low.
The first is speed. A paper version can be ready tonight. A landing page takes an afternoon. The faster you can test, the more times you can test, and several honest rounds teach you more than one polished attempt ever will.
The second is honesty. People treat rough things differently from finished ones. Show someone a slick, finished product and they comment on colors and fonts, because it looks done and criticizing the core idea feels rude. Show them a sketch and they tell you the idea does not make sense to them, which is the feedback you need.
The third is emotional. The more you invest in a prototype, the harder it becomes to hear that it is wrong. A version that cost you twenty dollars and an evening is easy to throw away. A version that cost you a year is not, and founders in that position tend to explain away the bad news rather than act on it.
The menu of low fidelity methods
There are more ways to test an idea than most founders realize. Each one is good at answering a particular kind of question.
A paper prototype or sketch is a hand-drawn version of the screens, forms, or steps a customer would go through. You put it in front of someone, ask them to do a task, and watch where they get confused. It is best for testing whether a flow makes sense before anything is built.
A storyboard or short explainer video shows the before and after: the customer's problem, what they do with your product, and how life looks afterward. It tests whether people understand the outcome and want it, without building the product at all.
A landing page smoke test is a single web page describing the offer as if it exists, with a button to sign up, join a waitlist, or pre-order. Send a small amount of traffic to it, from a community you belong to, a few posts, or a modest ad budget, and measure what strangers do. It tests demand. If you run ads, the cost of each signup gives you an early, rough sense of what customers might cost to win, and a customer acquisition cost calculator helps you see whether that number could ever work.
A concierge test means delivering the result by hand to a handful of customers. Rosa wanted to start a sourdough subscription, so before buying a second oven or building a website, she took orders from twelve neighbors by text and delivered every Saturday for six weeks. She learned which loaves people reordered, which days worked, and that half her customers wanted to pause during summer travel. None of that required software.
A Wizard of Oz test looks automated to the customer but is run manually behind the curtain. Andre had an idea for a text message service that would remind people when to water and feed specific houseplants. Instead of building the scheduling engine, he took photos of each customer's plants and sent every text himself from a spreadsheet. Customers experienced the product. Andre learned whether they valued it before writing a line of code.
A clickable mockup is a set of linked screens built in a design tool, with no real system behind them. It tests usability and specific screens with real people. Mei used one for a booking tool aimed at independent hair stylists and found in her first three sessions that stylists cared far more about deposits for no-shows than about the calendar view she had spent most of her time on.
A pre-order or deposit asks people to put real money down for something that is not finished. It is the strongest signal of willingness to pay you can get, because it costs the customer something. If you are unsure how to set the number, setting a price for your product or service walks through it.
A rough physical sample is a handmade, 3D printed, or kitchen-batch version of a physical product. It tests form, feel, size, or taste. Kevin could have sewn three bags of different sizes by hand and put them in the hands of twenty people.
Choose by your riskiest assumption
With so many options, the way to choose is to start from the assumption that would sink you if it turned out to be wrong.
Every idea rests on a stack of assumptions: people have this problem, they will understand the solution, they will pay this price, you can deliver at this cost, you can reach them through these channels. Some of these you already have decent evidence for from your customer interviews. Others are pure guesses. The riskiest one is the guess that is both uncertain and fatal if wrong.
Match the method to that assumption. If the risk is "people will not pay," a pre-order or a landing page with a price on it tests it directly, and a paper sketch tells you nothing. If the risk is "people will not understand how to use it," a clickable mockup or paper prototype is right, and a landing page tells you nothing. If the risk is "the outcome is not valuable enough to keep paying for," a concierge test is hard to beat, because people experience the real result over and over.
Pick one assumption per test. Trying to test everything at once produces muddy results that cannot be traced to any single cause.
Set pass or fail criteria before you start
This is the step that separates testing from wishful thinking. Before anyone sees your prototype, write down what result would count as a pass, and make it a number.
"People like it" is not a criterion. "At least 15 of the first 200 visitors join the waitlist" is. So is "at least 3 of 5 testers complete the booking without help," or "at least 8 of 12 concierge customers reorder in week three." Set the timebox too: how many days the test runs and how many testers you are aiming for.
The reason to commit in advance is that once results come in, the human mind is very good at reframing them. Eleven signups out of 200 feels encouraging if you never wrote down 15. Without a bar set beforehand, almost any result can be read as a reason to keep going, and that is how founders end up a year later still "seeing promising signs."
The number does not have to be perfect. It has to be honest, specific, and set before you look.
Watch what people do, not what they say
Feedback from a prototype test comes in two forms: what people say and what they do. Behavior is far more reliable.
When you run a paper or clickable test, give the tester a realistic task and then stay quiet while they try it. Note where they hesitate, what they tap first, where they go back. Resist explaining. If you have to explain, the design failed at that spot, and that is the finding.
For a landing page, the clicks and signups are the behavior. For a concierge or Wizard of Oz test, the behavior is whether customers keep using it, reorder, or refer a friend. For pre-orders, it is whether money changes hands.
Still capture what people say, especially in their own words, but grade it by strength. "This is cool" is the weakest signal there is. "When can I get it?" is stronger. A verbal yes with no commitment is better than a maybe, and a payment is better than all of them. Keep a short record for each tester: did they complete the task, what did you observe, what did they say, and how close did they come to paying.
Decide: go, iterate, or stop
At the end of the timebox, compare the result to the bar you set. There are three honest outcomes.
Go means you cleared the bar and the riskiest assumption held up. Move to the next riskiest assumption, or, if the big ones are covered, start building a slightly higher fidelity version.
Iterate means you learned something specific that suggests a change, and the change is worth testing. Mei's stylists did not reject her idea. They told her through their behavior that deposits mattered more than scheduling, so her next mockup led with deposits.
Stop means the core assumption failed and nothing you learned points to a fix. This is the hardest call and the most valuable one. A stopped test that cost two weeks and a hundred dollars has saved you the year and the savings that Kevin spent. Stopping one idea also frees you to test the next one, which is how a lot of good businesses actually get found.
Write down the decision and why. Future you will want to know what you knew at the time.
The mistakes that waste a prototype
The most expensive mistake is building too much. Founders routinely spend months on something that could have been tested in a weekend, usually because the prototype was treated as version one of the product rather than as a question.
Testing on friends and family is close behind. They want you to succeed, so they are generous, and generous feedback teaches you nothing. Find strangers who match the customer you described in your interviews.
Moving the goalposts is common and quiet. A founder named Jordan set a bar of 40 pre-orders, got 9, and decided the real test was "awareness," which needed more time. Then he set no new bar. Months later he was still waiting for awareness to arrive. If a test misses, you can choose to iterate, but write down the new bar and the new deadline before you start the next round.
Asking instead of watching rounds out the list. A survey asking "would you use this?" is a prediction, and people are poor predictors of their own behavior. Put something in their hands and watch.
PushStartGo built the prototype step of the Founder Workbook around these exact traps. It walks you through naming your riskiest assumption, choosing from the methods above, and setting a timebox and tester target. It will not accept a success bar without a number in it. Each tester gets a feedback entry that separates what they did from what they said and records how close they came to paying. And the test does not count as finished until you have logged at least three testers and made a clear go, iterate, or stop call. It is a free step, and it pairs with the customer discovery step that comes before it.
Back to the garage
Kevin did sell the bags, eventually, by narrowing his customer to shift workers and slashing his price to clear inventory. The second design, a larger bag, he tested differently. He sewed ten samples by hand, lent them to ten nurses at a nearby hospital for two weeks, and asked for a deposit from anyone who wanted one when they handed the sample back. Seven of the ten paid. That was his pass bar, written on an index card taped above his sewing machine before the first sample went out.
That is the whole method. Ask one question, with the cheapest thing that can answer it, and decide in advance what answer counts. You cannot plan your way to a business, and a rough prototype is the fastest form of doing there is.
Before you test, make sure you know exactly what you are claiming with a sharp value proposition that is not generic. Then pick your riskiest assumption, set your bar, and start in the Founder Workbook to plan the test and log what your testers do.