How to test a business idea after you build it

Back to that demo day. The founders who had good answers to the investors, the ones who could say what customers told them and what the market did, had one thing in common. They had put something in front of real people. Not a finished product. Just enough to get a reaction. That is what this article is about.

Building that something is almost free now. Lovable (an AI tool that builds working apps from plain-English prompts) published the story of Yannis, a marketer who built a working product called PrintPigeon in three days for $38 in credits, then liked the tool so much he joined the company. He is not a developer. A weekend and pocket money now buys you a clickable thing.

Here is the part that matters for testing. You do not build that prototype to ship it. You build it to fake the idea well enough that a real person reacts to it. It is bait. A working screen pulls a reaction out of someone that a slide never will. They open it, get lost, light up, or ask "what is this for?", and that reaction is the signal. The prototype is a testing instrument, not the product.

So this is not about usability, whether the button sits in the right place. It is about the idea. Do people want this, will they act, will they pay. A fake, clickable prototype is the sharpest way to ask.

One warning before real people touch it. Veracode (an application-security company) ran the same coding tasks through more than a hundred AI models and found that 45% of the generated code carried a known security hole.

The rule from the first article still holds, even with a slick prototype in your hand.

The Mom Test does not stop when you have a demo. Open with the conversation, reveal the fake, then watch and stay quiet. And be honest about what a same-day test gives you: reactions, not results. When Ionian Technologies tested a finished-looking app on the street in Thessaloniki, one person spent ten minutes and never found an outfit, another tapped an outfit expecting details that were not there, and a third could not say what the app was for. Heavy findings, in a day instead of a quarter. The prototype looked done. The reactions told the truth.

Six ways to test the idea with a fake prototype follow.

Put the clickable prototype in front of five people who match your target, give them a real task, and go quiet. Start with the conversation, then hand over the screen. This is the core of Teresa Torres's continuous discovery: small, frequent tests with real customers, watching what they do rather than asking what they think.

A reaction to a real screen is far stronger evidence than an opinion about a description. Use it for any idea you can fake in a day. Do not lean on it for hard demand numbers, it is qualitative, so pair it with one of the behaviour tests below.

Make the front look like finished software, then do the work behind it by hand. The user believes it is real, so they behave naturally. Nielsen Norman Group (a respected UX research firm) has a clear write-up of the method. The classic example is Zappos: in 1999 Nick Swinmurn photographed shoes in a local store and bought pairs at retail when someone ordered, before building any of the machinery.

A vibe-coded prototype is the perfect believable front for this. Use it to test demand for an expensive-to-build experience, matching, logistics, or an AI feature, without building the expensive part. Skip it when doing the work by hand cannot meet the quality or speed the test needs.

You can run a fake door inside a real-feeling prototype, not just as an ad. Add buttons or menu items for features that do not exist yet. When someone clicks, show an honest "coming soon" and log it. This is Alberto Savoia's pretotyping, moved inside the product, where the clicks mean more because the surroundings feel real.

It tells you which features people actually want, ranked by clicks, before you build a single one. Use it to decide what to build next. Do not run the same fake door on the same people over and over, or you spend their trust.

Record a short clickable demo that shows the idea working, post it where your audience is, and put a waitlist form under it. Drew Houston did this for Dropbox in 2007 with a demo video before the product was built, and it turned a hard-to-explain idea into a queue of signups.

It sells an idea people cannot picture from words, and it scales past the handful you can interview. Use it when the product is hard to grasp in text. Skip it if you cannot make a convincing demo.

This is the test investors are really asking about. Add a "choose plan" or "buy" step to the prototype, and wire it to a checkout, or to a "launching soon, reserve your spot" capture. A click on the price, and better, a card entered, is the strongest signal you can get without shipping. Buffer's Joel Gascoigne built a pricing page behind the button for exactly this reason, to test whether people would pay, not just whether they liked it.

Use it once you want a real demand read at a real price. Handle it honestly: do not take money you cannot refund, and tell people clearly when the product is coming.

Once people will pay, find out how much. For a quick read, ask the four Van Westendorp questions, at what price the product feels too cheap, cheap, expensive, and too expensive, and find the band where most people are comfortable. Sawtooth Software, a pricing-research firm, has a solid explainer. Better still, run the prototype checkout at two prices and see who actually pays.

It moves you off a number you guessed. Use it when you are setting a first price. Trust a real charge over a stated one every time, because what people say they will pay and what they pay are different numbers.

No build or one-day build: which test to reach for

Almost every one of these has a no-build cousin from the first article. The prototype is worth the day only when it makes the test stronger, not when it makes you feel productive. Here is the honest map.

The pattern is simple. Lead with conversations to learn whether the problem is real, then let a prototype confirm it with an aha moment, shown second and never first. Build when you need to test whether people want the solution, which features pull, and whether they will pay, because those get sharper when there is something real to click.

Where this leaves you

The build got you a reaction. The reaction was the point, not the build.

If you have not read it, start with how to test a business idea before you build it. The full method and the worksheets are free at productbuildday.com/playbook. Run one, then tell me how it went. You ran it, you get the credit.

Frequently asked questions