Commercial Validation Engine

How to validate a startup, SaaS, product or service idea
before you build or spend.

Before you write code, make a product, commit to inventory, staff a service or spend on delivery, name the assumption that would sink the idea if it were wrong. Then run the cheapest credible test that could change your decision.

Evidence gets stronger as it moves from opinion to observed behaviour to something the buyer puts at stake. A test has done its job when the result changes what you do next: build, narrow the idea, run another test, or stop.

Some things cannot be known yet. Retention, repeat purchase, real conversion and lifetime value need customers using and paying for a working product or a repeatable service, so no pre-build test settles them.

Six assumptions to test across any idea formatWhat each test can and cannot showNo universal pass marks

How to validate market demand before you build an MVP

Validate market demand before an MVP by testing whether the problem is real, whether the right buyer can be reached, whether the current workaround is painful enough to challenge, and whether someone will take a consequential next step before a working product exists.

That evidence can justify building, narrowing, testing again or stopping. The MVP then tests product use, delivery, adoption and other questions that pre-build demand evidence cannot settle.

A founder weighing evidence before deciding whether to build, make, or deliver an idea

How the same commercial questions apply to software, physical products and services

The commercial questions are the same across formats: is the problem real, who has it, what do they do today, can you reach them, will they put something at stake, and is there a plausible path from that buyer to a business? The test changes with the thing being offered. The evidence boundary does not.

Software: test the problem, current workaround, buyer access and willingness to commit before you build features. An offer response, design-partner commitment or paid pilot can inform the next decision. None establishes adoption, retention, reliability or scalable delivery before people use the product.

Physical product: test the problem, buyer and willingness to commit before tooling, a production run or inventory. A prototype, deposit or pre-order can inform whether a buyer will put something at stake. It does not establish manufacturability, safety, certification, unit yield, returns, fulfilment capacity or repeat purchase.

Service: test the problem, buyer, delivery promise and willingness to pay before hiring, building operations or spending on acquisition. A paid trial, pilot or manual delivery can inform whether the outcome is worth buying. It does not establish repeatable delivery, staffing capacity, margin, quality at scale or renewal.

Already launched and wondering why nothing converts? That is a different question: read the traction diagnosis.

Building SaaS specifically? Read the SaaS validation guide for recurring workflow, buyer, current stack, switching-friction, pilot and paid-commitment questions before choosing a method.

Six assumptions to test before you build, make or deliver

The free check reads public market evidence, so it speaks to the problem and the current workaround. Buyer, reachability, commitment and the commercial path are not settled by it: the first three are yours to test, and the last is what the paid stages work on. That boundary is the same whether the idea is software, a physical product or a service.

01

Problem

Is the problem real, recurring and costly enough that someone is already trying to deal with it?

What counts as evidence: People describing the problem in their own words, unprompted, and describing what it costs them in time, money or risk.

Public market evidence (the free True Validation check)A test you run yourself, before building
02

Buyer

Who feels this problem, and who decides whether anything is done about it?

What counts as evidence: A description of the person and the setting specific enough that you could find ten more like them this week, and an account of who holds the budget and who can say no.

A test you run yourself, before buildingLater paid work, Stages 2 to 6Stage 2: Buyer Precision
03

Current workaround

What do they do today, and what does that alternative already cost them?

What counts as evidence: The spreadsheet, the manual process, the incumbent tool, the existing supplier, the existing service, or the decision to live with it, described in enough detail that you can see where it breaks.

Public market evidence (the free True Validation check)A test you run yourself, before building
04

Reachability

Can you get in front of these buyers repeatedly, without relying on a one-off favour?

What counts as evidence: A repeatable way you actually reached them: a community, a list, an introduction path or a channel you can use again next week.

A test you run yourself, before buildingLater paid work, Stages 2 to 6Stage 4: Revenue Funnel, Stage 5: Market + Funnel
05

Commitment

Has any buyer put something at stake rather than saying the idea sounds good?

What counts as evidence: Access, time, data, a dated next step, a pilot they helped set up, a deposit, a pre-order or money. What matters is what they gave up, not how positive they sounded.

A test you run yourself, before building
06

Commercial path

Is there a plausible route from this buyer to a business, and what would have to be true for it to hold?

What counts as evidence: A stated path to price, delivery and repeat purchase, with the parts you cannot yet know written down as open questions rather than assumed answers. For a physical product or service, this includes delivery and operating constraints that need their own feasibility work.

Later paid work, Stages 2 to 6Stage 3: Buyer + Offer, Stage 4: Revenue Funnel, Stage 6: Commercial Decision

The paid stages continue the same questions with evidence a pre-build test cannot reach: Stage 2: Buyer Precision, Stage 3: Buyer + Offer, Stage 4: Revenue Funnel, Stage 5: Market + Funnel, Stage 6: Commercial Decision.

GTM Right Canvas is a one-time £349 purchase for one idea and 90 days. It includes paid work across Stages 2 to 6: Buyer Precision, Buyer + Offer, Revenue Funnel, Market + Funnel, Commercial Decision. It delivers Paid Canvas work across Stages 2 to 6 and Commercial Readiness Pack. It is for the commercial questions your own tests leave open; it does not replace those tests, and buying it does not change what they showed.

Acquisition cost, payback and lifetime value are not pre-build gates. They need real spend and real customers, which is Stage 4: Revenue Funnel work, not something a pre-build test can settle.

Which validation method proves what?

Most lists of product idea validation methods, startup validation methods or demand validation methods name the techniques and stop there. The question that decides which one to use is narrower: which assumption does the method test, what can its result support, and what can it not establish? Seven method families cover the common techniques, because several of the names describe the same decision.

Methods generate evidence. The evidence rubric interprets how strong a buyer signal in that evidence is. The same method can produce a weak or a strong signal depending on what the buyer actually did, so the grade belongs to the result, not to the method. The grade shown for each family is the one its result usually reaches.

The five practical dimensions below describe what each method asks of you, as editorial guidance. They are not measured costs or durations. No figure is given, because none would hold across different ideas, buyers and markets.

01Problem interviews

Politeness

Also called: Customer interviews, Discovery interviews. Tests: Problem, Buyer.

Action:
Ask people who should have the problem about the last time it happened, what they did, what it cost and who else was involved, before you describe any possible solution, product or service.
Evidence produced:
Accounts of real incidents in the buyer's own words, with the cost and the workaround attached.
May support:
That the problem recurs, costs something, and sits with a particular kind of person.
Cannot establish:
That anyone will pay, or that your solution is the one they want. Agreement in a conversation is not a decision. The interview tests a problem and its current workaround. It does not test whether you can make, deliver or operate the proposed answer.
Stronger next test:
Ask to see the workaround in use, then ask what would have to be true for them to replace it.
How the signal reads:
Usually Politeness, sometimes Interest. Warm words about the problem are not a signal about your offer.
Founder effort
Your own time finding the right people and holding the conversations.
Technical effort
None.
Participant access
People who have the problem have to agree to talk to you.
Money changes hands?
No.
Working product needed?
No.

02Public complaint and workaround research

Not a buyer signal

Also called: Complaint research, Review mining. Tests: Problem, Current workaround.

Action:
Read what people say about the problem unprompted in public: complaint threads, review platforms and relevant specialist communities, including what they say current tools get wrong.
Evidence produced:
Descriptions of the problem and its workarounds from people you did not ask. Complaint threads, reviews, specialist communities, trade forums and public buyer discussions can reveal problem and workaround language. They are evidence about the problem, not proof that a buyer will choose a proposed software product, physical product or service.
May support:
That the problem is visible beyond your own contacts, and the language buyers use for it.
Cannot establish:
Who would buy, what they would pay, or whether they would switch. Public complaint shows the problem, not demand for your answer to it.
Stronger next test:
Take the buyers' own words into problem interviews and test whether the pain is recent and costly.
How the signal reads:
Not a buyer signal about your offer. It is evidence about the problem, so the rubric does not grade it.
Founder effort
Desk research: finding and reading the right public sources.
Technical effort
None.
Participant access
None. The sources are already public.
Money changes hands?
No.
Working product needed?
No.

03Current-solution research

Not a buyer signal

Also called: Competitor research, Alternative mapping. Tests: Current workaround.

Action:
Map what buyers use or buy today, what they tolerate, and what changing supplier, product, workflow or provider would cost in effort, data, risk, money and internal politics. Include existing tools, suppliers, service providers, internal processes and doing nothing.
Evidence produced:
A picture of the alternative, its price, and the cost of moving away from it.
May support:
Whether there is room for a better answer, or whether the current one is good enough.
Cannot establish:
That anyone will actually move. Switching cost is not measured by reading about it.
Stronger next test:
Ask buyers what would have to be true for them to replace what they use today.
How the signal reads:
Not a buyer signal about your offer. It describes the alternative, so the rubric does not grade it.
Founder effort
Desk research, plus the questions you add to problem interviews.
Technical effort
None.
Participant access
Mostly public material, with some detail that only buyers can give you.
Money changes hands?
No.
Working product needed?
No.

04Offer response test

Interest

Also called: Landing page, Smoke test, Fake-door variant, Sales page, Concept card, Prototype enquiry. Tests: Reachability.

Action:
Put a clear description of the offer in front of the buyer you named, through a channel you could use again, and ask for a response that costs them something: a booked call, a scoped conversation or a request to be a first user.
Evidence produced:
What people did when shown the offer, and how much effort it took to put it in front of the right ones.
May support:
That the promise is understood, and that a channel can reach the buyer and produce action.
Cannot establish:
Willingness to pay. A click or a signup is not a purchase, and a response to a description is not a response to a working product.
Stronger next test:
Ask the people who responded for a dated next step, a deposit or a pre-order.
How the signal reads:
Usually Interest. A request for a dated next step moves it towards Intent.

In the fake-door variant, the button or signup leads to something that does not exist yet. Say plainly what happens next, because a dead end tests your wording at the cost of the visitor's trust, and the click it records says less than it appears to. For a physical product or service, make clear what is real now, what is a concept or prototype, and what happens after a buyer responds.

Founder effort
Writing the offer, and putting it in front of the right people rather than any people.
Technical effort
A page or a message. No finished product is required. A message, concept card, sales page or prototype enquiry can test whether the promise is understood.
Participant access
A channel that actually reaches the buyer you named.
Money changes hands?
Not usually. Asking for a deposit turns it into a commitment test.
Working product needed?
No. In the fake-door variant, nothing exists behind the interaction.

05Manual delivery test

Intent

Also called: Concierge, Wizard-of-Oz variant. Tests: Problem, Commercial path.

Action:
Deliver the intended outcome by hand, through a prototype, or through a deliberately manual service for one buyer, and watch whether they want it again and what it actually took to produce.
Evidence produced:
Whether the outcome is wanted a second time, and what delivering it really involves.
May support:
That the outcome has value, and what the product would really have to do.
Cannot establish:
It cannot establish that a product can be manufactured safely, that a service can be delivered repeatedly by others, or that the outcome can be delivered economically at scale. Doing it by hand for one buyer hides the cost of doing it for many.
Stronger next test:
Charge for the manual delivery, then see whether the buyer pays again.
How the signal reads:
Usually Intent, because the buyer gives time and attention to receive it. Paying for it makes it Commitment.

In a concierge test the buyer knows the outcome is delivered by hand. In the Wizard-of-Oz variant the manual work is hidden behind something that looks like a working product, which tests the experience as well as the outcome. Hiding it carries a trust cost if the buyer later feels misled, so decide in advance what you will tell them.

Founder effort
You do the work the product would do, by hand, for each buyer.
Technical effort
Little or none for a concierge test. The Wizard-of-Oz variant needs a front end convincing enough to use.
Participant access
A buyer willing to receive the outcome and tell you what happened.
Money changes hands?
Sometimes. Charging for it makes it a commitment test as well.
Working product needed?
No. The point is to test the outcome before automating it.

06Design partner or pilot

Intent

Also called: Design partner, Free pilot, Proof of concept. Tests: Commitment, Buyer.

Action:
Ask a named buyer to work with you: to define what success means, give access or data, and set a date. Write down what they are giving up by taking part.
Evidence produced:
What they committed, who else they involved, and whether the work survived contact with their calendar.
May support:
That the problem is prioritised now, and who else is involved in a decision.
Cannot establish:
That a free pilot converts to payment, or that other buyers share this buyer's needs. A free pilot is evidence of time and access, not willingness to pay.
Stronger next test:
Attach a term that costs something: a fee, a purchase order, a start date or a named payer.
How the signal reads:
Usually Intent. A pilot with a fee or a named payer moves it towards Commitment.
Founder effort
Running the work alongside the buyer's own, often over several meetings.
Technical effort
A representative prototype, partial working version, sample product, or manual delivery that lets the buyer assess the relevant outcome.
Participant access
A named buyer who agrees to give time, access or data.
Money changes hands?
Not in a free pilot. In a paid pilot it does, which makes it a commitment test.
Working product needed?
Usually a partial version, or a manual one standing in for it.

07Commitment test

Commitment

Also called: Pre-sale, Deposit, Pre-order, Paid pilot, Signed order. Tests: Commitment, Commercial path.

Action:
Ask for the commitment that carries economic consequence, with the person who controls the budget involved.
Evidence produced:
Whether someone with budget acted at a price, and what they expected in return.
May support:
That a buyer with budget acted on the problem at a price.
Cannot establish:
Retention, renewal or lifetime value, which need a product that exists and is used, or that one buyer's commitment will repeat.
Stronger next test:
Ask a buyer who owes you no favour for the same commitment.
How the signal reads:
Commitment, when the buyer genuinely puts money or an obligation at stake.
Founder effort
Asking for money, and agreeing terms with whoever controls it.
Technical effort
Depends on what is promised. A deposit, pre-order or paid pilot can happen before a finished product or service exists, provided the buyer is told what will be delivered and when.
Participant access
The buyer and the person who holds the budget.
Money changes hands?
Yes. That is the point of the test.
Working product needed?
Not for a pre-sale or deposit. Delivery follows the commitment.

Choosing a validation method by situation

Choose by circumstance, not by category. These questions decide which method is realistic and informative for the assumption you are testing.

Can you reach buyers directly?
If you can, problem interviews and design partners are within reach. If you cannot yet, public research and an offer response test tell you whether a channel exists at all.
Can money change hands before the product exists?
If a buyer can pay for a promise, a pre-sale or deposit is the strongest pre-build evidence available. If they cannot, for example where buying requires a working product to evaluate, a design partner or pilot is the realistic route to commitment.
Can the result be delivered by hand?
If it can, a manual delivery test shows whether the outcome is worth having before you automate it. If the value only exists once software runs at scale, rely more on offer response and commitment tests.
Do procurement or a separate payer matter?
Where the person who uses it is not the person who pays, test the payer as well. A user's enthusiasm is not a budget decision.
Does the test need a functioning product?
Most pre-build tests do not. If yours does, you are closer to a pilot than a pre-build test, and questions about retention start to apply.
Does the idea require a physical product, regulated process or specialist delivery?
Run the commercial test and the feasibility work separately. A buyer's interest, deposit or pre-order can inform demand. It does not prove safety, certification, manufacture, inventory, fulfilment, licensing or operating capacity.
Does the proposed service depend on the founder's own time or specialist judgement?
Use a manual delivery or paid trial to learn whether the outcome is worth buying, then record what delivery actually took. A single founder-led result does not establish that the service can be staffed, repeated or delivered profitably.

A business selling to other businesses often has fewer buyers, harder access and a separate payer, which can make design partners, pilots and payer involvement more informative. A consumer product can often put an offer or pre-order in front of many people quickly. A physical product may need a prototype or sample, while a service may be delivered manually first. These are tendencies, not rules: choose by the assumption, the buyer's decision, and what the test can actually establish.

What signals count before you build, make or deliver

GTM Right's working interpretation of its evidence rubric for the pre-build case, not a universal standard.

GTM Right's working rubric, not a universal research taxonomy.

A conversation about the idea

Politeness
Can show:
Whether the problem is recognised, and the language the buyer uses for it.
Cannot show:
Whether anyone will change what they do, or pay.
Stronger next test:
Stop discussing the idea. Ask what happened the last time the problem occurred, and what it cost.

An observed workaround: the spreadsheet, the manual process, the tool they pay for today

Interest
Can show:
That the problem is real and is already costing someone time or money.
Cannot show:
That they will buy your version of the solution. This is evidence about the problem, not proof of demand.
Stronger next test:
Ask to see the workaround in use, then ask what would have to be true for them to replace it.

Access or time given: a working session, their data, an introduction to the person who decides

Intent
Can show:
That the problem is worth spending scarce time on, and who else is involved in a decision.
Cannot show:
What they would pay, or whether the spend survives a budget conversation.
Stronger next test:
Ask for a dated next step with someone who controls budget attached to it.

A design-partner or pilot action: they help scope it, name success, or set a date

Intent
Can show:
That the problem is prioritised now rather than in principle.
Cannot show:
That the pilot converts to payment, especially where the pilot costs them nothing.
Stronger next test:
Attach a term that costs something: a fee, a purchase order, a start date or a named payer.

Economic commitment: a deposit, a pre-order, a paid pilot, a signed order

Commitment
Can show:
That someone with budget acted on the problem at a price.
Cannot show:
Retention, renewal or lifetime value, which need the product to exist and be used.
Stronger next test:
Test whether the same commitment repeats with a buyer who owes you no favour.

Stated interest in a conversation is not commitment. The full four-grade rubric, with the self-check, is on the traction diagnosis page.

The pre-build sequence, and what each result should change

There is no number of interviews, signups or conversion rate that makes an idea validated. The test is whether the evidence you have would change your decision, and whether the next cheapest test could change it again.

01

Problem interviews

Assumption: Problem

Action: Talk to people who should have the problem. Ask what happened the last time it occurred, what they did, what it cost and who else was involved. Do not describe your idea until the end.

Evidence produced: Accounts of real incidents, in the buyer's words, with the cost and the workaround attached.

Build: Not yet. Nothing here is purchase evidence on its own.

Narrow: The problem is sharp for one kind of person and vague for the rest. Follow the sharp one.

Test again: People recognise the problem but cannot recall a recent instance. Find buyers closer to the pain.

Stop: Nobody can describe the problem happening, and nobody does anything about it today.

02

Public complaint and workaround research

Assumption: Problem

Action: Look for people describing the problem unprompted in public: complaint threads, review platforms and relevant specialist communities. Read what they say the current tools get wrong.

Evidence produced: Unprompted descriptions of the problem and its workarounds, from people you did not talk to.

Build: Not on its own. Public evidence tells you the problem is visible, not that anyone will buy.

Narrow: The complaints cluster around one setting or one job. Narrow to that cluster.

Test again: You find noise but no specifics. Change the search language to the words buyers used in interviews.

Stop: The problem is nowhere in public and no one you interviewed has acted on it.

03

Current-solution research

Assumption: Current workaround

Action: Map what buyers use today, including doing nothing. Find what they already pay for, what they tolerate, and what switching would cost them in effort, data, risk and politics.

Evidence produced: A picture of the alternative, its price, and the cost of moving away from it.

Build: Not yet. Knowing the alternative is weak is not the same as knowing anyone will move.

Narrow: One segment is badly served by the incumbent while others are content. Narrow to the underserved one.

Test again: The alternative looks adequate. Test whether the pain you found is worth the switching cost at all.

Stop: Buyers are content, or switching costs are so high that no reachable buyer would move.

04

Offer response test or manual delivery test

Assumption: Reachability

Action: Run an offer response test: describe the offer to the buyer you named and ask for a response that costs something, such as a booked call, a scoped conversation or a request to be a first user. Where the outcome can be delivered by hand, run a manual delivery test instead and deliver it yourself for one buyer.

Evidence produced: What people did when asked, how much effort it took to reach them, and, for a manual delivery, whether they came back for more.

Build: Not yet, though a manual delivery someone keeps asking for is a strong reason to continue.

Narrow: One message or one audience does the work. Narrow the offer to that promise.

Test again: You could not reach enough of the right people to learn anything. Change the channel, not the claim.

Stop: You can reach the buyer, they understand the offer, and they still do nothing.

05

Design-partner or pilot test

Assumption: Commitment

Action: Ask a named buyer to work with you: to define what success means, to give access or data, and to set a date. Write down what they are giving up by taking part.

Evidence produced: What they committed, who else they involved, and whether the work survived contact with their calendar.

Build: Buyers commit their own time and people, and the scope they ask for is one you can deliver.

Narrow: They commit only to a smaller part of the problem. Build that part.

Test again: They agree in principle but nothing gets scheduled. Ask for the commitment that has a date on it.

Stop: Nobody will commit anything beyond encouragement.

06

Commitment test

Assumption: Commitment

Action: Ask for the commitment that carries economic consequence: a paid pilot, a deposit, a pre-order or a signed order, with the payer involved.

Evidence produced: Whether someone with budget acted at a price, and what they expected in return.

Build: A buyer with budget commits at a price you can live with, and you can name who the next ones are.

Narrow: They commit for a narrower scope or a lower price. Take the scope and note the price question.

Test again: The commitment stalls with the payer. Find out what the payer needs to see and test that.

Stop: The offer is understood, the buyer is the right one, and nobody will commit anything that costs them.

What counts as commitment before you build, make or deliver

Waitlist signup

Can show: That the promise is understood and interesting enough to leave an address for.

Cannot show: That anyone will pay, or that the signup will answer you later.

Design partner

Can show: That a buyer will spend their own time and expose their process to shape the product.

Cannot show: That the wider market shares their needs, or that they will buy what they helped design.

Free pilot

Can show: That the problem is worth a slot in their calendar and permission to be inside their process.

Cannot show: Willingness to pay. A pilot that costs the buyer nothing leaves the price question untested.

Paid pilot, deposit, pre-order or paid trial

Can show: That someone with budget acted at a price, before the product was finished.

Cannot show: That the price holds at scale, that delivery is repeatable, or that the buyer renews or repurchases.

Procurement or payer involvement

Can show: That the purchase is being treated as a real one, with the people who can approve or block it in the room.

Cannot show: The outcome. Procurement involvement is a sign of seriousness, not a decision.

Signed commercial commitment

Can show: That terms were agreed and someone accepted an obligation.

Cannot show: Delivery, repeatable operations, retention or renewal. Those questions begin only once the product or service is being used.

The evidentiary weight of an LOI depends on its actual terms and binding status; the document label alone is not the same as payment.

One illustrative software example, not a real result

Illustrative software example, not a real company, customer result or benchmark.

This example uses a software idea because it illustrates the sequence clearly. The evidence rule is not software-specific. For a physical product or service, the delivery test changes, while the distinction between opinion, observed behaviour and commitment remains the same.

A SaaS tool that reconciles supplier invoices against delivery notes for independent wholesalers.

01. Problem interviewsNarrow

Interviews find that the reconciliation pain is real for wholesalers with several depots, and barely registers for single-site ones.

Why that decision: The problem is sharp in one setting and vague in the other, so the second group leaves the test.

02. Public complaint and workaround researchContinue

Public complaint threads describe the same mismatch problem, usually as an argument with an accounting package rather than a missing product.

Why that decision: The problem is visible unprompted, though it says nothing yet about who would buy a separate tool.

03. Current-solution researchContinue

The current workaround is a shared spreadsheet plus a monthly argument with the supplier. The incumbent accounting tool is kept for other reasons.

Why that decision: Replacing the accounting package is off the table, so the offer has to sit alongside it rather than replace it.

04. Offer response test or manual delivery testRun another test

The offer is put to the narrowed buyer. Some book a call; reaching them at all depends on one trade community.

Why that decision: Reachability rests on a single channel, which is a different risk from the problem being real.

05. Design-partner or pilot testContinue

Two wholesalers agree to be design partners, give access to real invoice data and name what success would look like.

Why that decision: Buyers are spending their own time and exposing their process, which is intent rather than encouragement.

06. Commitment testContinue

Asked for a paid pilot, one commits with the finance lead involved. The other prefers to wait for the finished product.

Why that decision: One buyer with budget acted at a price. The split is the next thing to test, not a reason to assume the rest will follow.

Had nobody committed anything at step 5 or 6 while the problem, the buyer and the reach all held, the decision would have been to stop rather than to build and hope.

Questions founders ask about validating a SaaS idea

How do I validate a SaaS idea without writing code?

Test the assumptions before the software. Interview people who should have the problem about the last time it happened, study the workaround they use today, put a described offer in front of the buyer you named, deliver the outcome by hand where you can, and ask for a commitment that costs them something. None of these needs code, and each can change your decision before any is written.

Which tests actually show demand?

Tests in which a buyer gives something up. A booked call, access to their data, a design-partner role with a date, a paid pilot, a deposit or a signed order are stronger than opinion, because each costs the buyer time, exposure or money. Interviews and public complaints show that the problem is real; they do not show that anyone will buy your version of the solution.

How long should validating a SaaS idea take?

There is no correct duration. Validation has done its job for now when the evidence you hold would change your decision to build, narrow, test again or stop, and it resumes when the next cheapest test could change that decision again. Some questions, such as retention and lifetime value, cannot be settled before real customers use a working product, however long you test.

What does a waitlist prove?

That the promise is understood and interesting enough to leave an address for. It does not show that anyone will pay, answer you later or use the product, and the size of the list is not proof of demand. Ask some of the people on it for something that costs them, such as a scoped call, access or a deposit, and read what they do.

What is a design partner, and how do I find one?

A design partner is a buyer who spends their own time and exposes their real process to help shape the product. That shows the problem is a priority for them, not that the wider market shares their needs or that they will buy what they helped design. Look among the people who described the problem most sharply in interviews or public threads, and ask for a defined role: what success means, what access they will give, and a date to start.

When should I stop?

When you can reach the right buyer, they understand the offer, and nobody will commit anything that costs them; or when nobody can describe the problem happening and nobody acts on it today. Stopping on that evidence is a result, not a failure. If the evidence is thin only because you could not reach the right people, change the channel and test again before you stop.

One method among several: the free public-evidence check

The free Stage 1 check is one way to run public complaint and workaround research. It analyses public market evidence for the problem you describe and grades what it finds. It can help with problem and current-workaround evidence for software, physical products and services. It does not test product feasibility, safety, certification, manufacture, inventory, fulfilment, service capacity, licensing, buyer commitment, retention or unit economics. Usually under 90 seconds.

Problem interviews, design partners, pilots, pre-sales and other commitment tests are founder-run activities outside the free Stage 1 check.

A structured check can make assumptions explicit, apply repeatable evidence rules and record counter-evidence. It cannot manufacture primary evidence or replace format-specific feasibility work that has not been done.

True Validation tests public market evidence only: whether the problem is real, visible and urgent. It does not prove buyer budget, willingness to pay, offer fit, acquisition economics or full commercial viability.

Run the free Stage 1 check

Stage 1 of 6. Free. No account required.

Related

Commercial validation

What commercial validation means, how it differs from market validation, and the evidence standard behind both.

Traction diagnosis

Already launched and stalled? What interest, signups and a waitlist actually prove after build.

Holding a development quote

A quote answers what it costs to build and is silent on whether anyone pays. What to test before the deposit.

The research

The Failure Intelligence archive, what it is, and the limits of what it can show.

Run the free Stage 1 check

Public market evidence for the problem, graded, with the next proof named.