How to Validate a B2B SaaS Idea Before You Build Anything

You validate a B2B SaaS idea by finding the budget line your product would replace, running about ten discovery calls with whoever controls that line, and treating nothing short of a signed letter of intent as a real yes. A landing page proves little here: the person who clicks "sign up" is rarely the one who approves the spend.

Why doesn't a fake door work on a B2B buyer?

A fake door test works when the person looking at the page is also the person who decides to pay, and the decision takes seconds. Neither is true in B2B. A single buying decision typically involves several people: a user who feels the pain, a manager who controls the budget it would come from, and often an IT or security reviewer who has to sign off on anything new entering the stack. A click from one of them, or from a user who has no purchasing authority at all, tells you almost nothing about whether the company will pay.

The timeline breaks the test too. A landing page measures interest in a moment. A B2B purchase is a months-long internal negotiation you are not in the room for, one that has to clear an internal budget cycle and a review process a click cannot see.

Fake doors also fail in the specific way B2B punishes hardest: false positives that look like proof. Future Foundry, an experimentation consultancy, describes a real client of theirs, a B2B SaaS company, that tested an AI analytics feature for its project-management platform with a waitlist page, saw nearly 3,000 sign-ups and got 18 months of development budget approved, then found that only 3% of waitlist subscribers converted to trials, and 89% of those cancelled within 30 days. People who click "AI analytics" are curious. People with a budget for it are a different, much smaller group, and a fake door cannot tell them apart. As one guide to the method puts it plainly, in small or high-touch B2B accounts a single disappointed champion can cost more than the learning is worth.

None of this means B2B ideas can't be tested cheaply. It means the test has to run through a conversation with a budget holder, not a click from a stranger.

What is the budget line, and why start there?

Every piece of software a company buys comes out of somewhere: a line item already in a budget, a headcount cost it would offset, or a new request that has to be justified from scratch. In practice, the first two are far easier to win. The third usually is not, because someone has to argue for new spend during a cycle that was already planned.

Software purchase requests inside a company typically move through three stages: a department raises the request, the technical or IT team reviews whether it's genuinely needed, and procurement checks budget availability before approving the purchase. If you can't name which of these stages your buyer is even in, you don't have a live prospect, you have a conversation.

Asking "would you use this" gets a polite yes almost every time. Asking "what line is this coming out of, and who owns it" gets you either a name and a number, or silence, which is the more useful answer.

How do you find the budget line before you've built anything?

1. Write down the categories your product would sit inside: the software it replaces, the manual process it automates, or the headcount task it absorbs.
2. On every call, ask what the company currently spends on that category, in dollars or in hours of someone's time.
3. Ask directly who owns that budget. It is frequently not the person you are talking to.
4. Ask when that budget is set. Many companies set software budgets annually, so a "yes" in the wrong month can mean a wait of up to a year.
5. Ask what would have to be true for them to move money out of that line into your product.

If nobody can answer step 2 with a real figure, you have not found a budget line. You have found a feature request, and feature requests do not get invoiced.

How many discovery calls do you actually need?

Ten is the right size for a first pass: small enough to finish in two or three weeks by yourself, large enough that a pattern shows up instead of one flattering anecdote. A useful comparison point is founder-led sales in the earliest stage of a startup, where the standard advice is to spend all of your sales time talking to prospects rather than building a deck, and to run discovery calls where you listen more than you talk. That same playbook notes that founders typically close their first handful of customers, maybe five to ten, through direct relationships before any process is repeatable, which is exactly why the goal of your first ten calls is a pattern, not a sales pipeline.

The purpose of the call is not to pitch. Discovery is not pitching: the goal is to surface the prospect's pain points and earn the right to sell by understanding their current and desired state, not to talk about your product or vision. Concretely, that means every call should get you three things: confirmation the problem costs real money or time, the name of the budget line it would come out of, and the name of the person who owns that line. If a call ends without at least the first two, it was a nice chat, not evidence.

It also matters who you are calling. An ICP might be as specific as a B2B SaaS company with 50 to 200 employees, $5 million to $20 million in ARR, based in North America, and already using a specific stack. Discovery breaks down fast when you talk to companies too small to have a budget process at all, or too large to move without a procurement cycle you can't survive.

What turns a conversation into a real yes?

Nothing does, except a signature. Here is what each level of enthusiasm actually proves and what it doesn't.

Signal	What it proves	What it doesn't prove	Treat it as
"This sounds great" on a call	The problem resonates emotionally	Anyone will pay, or that this person can approve payment	A reason to keep asking, not a yes
A booked follow-up call	Mild curiosity, or politeness	Budget exists or has been identified	Progress, not validation
A named budget line and owner	The spend category is real and someone controls it	That the owner will choose you over the status quo	A qualified lead
A signed letter of intent	A specific person is willing to put their name to a specific price for a specific outcome	That they will renew, or that the product will work at scale	The only real yes before you build
A purchase order	Money has actually moved	Nothing beyond this deal	Confirmation, not discovery

A letter of intent only earns its place in that table if it is specific. It should name a price or price range, a start date, the budget line it draws from, and what has to be delivered for it to convert into a paid contract. A vague LOI that says a company is "interested in exploring a partnership" is a warmer version of the fake door: a signature that costs the signer nothing.

What does this look like in a worked example?

Here is a hypothetical example: say you are testing a tool that auto-generates compliance case notes for outpatient therapy clinics with 10 to 30 clinicians. You run ten discovery calls with clinic operations managers.

• 7 of 10 confirm the problem in their own words and put a number on it, saying compliance documentation costs a biller roughly 8 hours a week.
• Of those 7, 4 can name the actual line it would come from, in this case an existing "compliance and QA" budget of around $15,000 a year.
• Of those 4, 2 agree to sign a letter of intent for a paid pilot: $400 a month for three months, contingent on the tool integrating with their existing records system within 60 days.

That is $400 × 3 months × 2 clinics = $2,400 in committed pilot revenue in this hypothetical, sourced from a real budget line, before a line of code exists. It is a small number, and that is the point: it is real money attached to a specific person's name, which a fake door cannot produce at any volume. Ten calls that produce zero named budget lines is also a result. It tells you the category doesn't have a home in anyone's spending yet, which is a reason to change the wedge, not to run more calls hoping the eleventh is different.

What do you build once someone has signed?

Build only what the letter of intent requires, in the timeframe it names. YC's sales playbook for founders advises keeping a pilot short enough that the buyer gets real, hands-on use out of the product, rather than long enough for you to keep adding to it. Check in every couple of days so any bugs surface and get fixed before the next session. Scope is fixed by the LOI, and delivering exactly that scope, quickly, is what earns you the right to expand it later.

If you already know the budget line and the buyer but not yet the smallest version of the product that satisfies the LOI, this is the point where a tool like Unthinkable's AI advisor is useful: it exists to turn a specific commitment into a scoped MVP and a launch plan, rather than leaving you to size the build from instinct.

When do you walk away?

Walk away when ten calls produce plenty of sympathy and no named budget line, or when every named line already has a vendor sitting in it with no stated dissatisfaction. As a working rule, if you have no signed LOI after fifteen budget-focused calls, the category likely doesn't have the demand you're hoping for, at least not from the buyers you're reaching. If it takes thirty calls to get one signature, the product may still work, but the sales motion or the buyer you're targeting is wrong, and that is worth fixing before it's worth building.