How to Know If People Will Pay for Your SaaS Before You Build It

People will pay for your SaaS when three things are true. They already spend money or hours on the problem. They commit something that costs them, such as a deposit, a signed letter of intent or a paid pilot, at a price you name. And that price sits inside the range they consider normal for the job. Compliments, survey answers and waitlist sign-ups tell you none of this.

This guide covers how to collect each kind of evidence, in the order that wastes the least time. It follows one example idea throughout, a tool that reconciles Stripe payouts with QuickBooks for small agencies, so every step has something concrete to point at. Swap in your own idea as you read.

Why "would you pay for this?" gets you a false yes

When you describe an idea and ask whether someone would pay for it, you are asking them to predict their own behaviour while you watch. Most people answer kindly. Rob Fitzpatrick's book The Mom Test builds a whole interview method around this problem: ask about what people did in the past, because opinions about the future cost nothing to give and nothing to get wrong.

Skipping this step is expensive. CB Insights' review of failed venture-backed startups found that most ran out of money, and that poor product-market fit, cited in 43% of cases, was one of the most common reasons the money ran out.

So the job is to replace opinions with behaviour. The useful question changes from "would you pay?" to "what do you pay now, and what would make you move that money to me?"

The willingness-to-pay evidence ladder

Evidence is worth as much as it cost the person to give it. Rank everything you collect on this ladder, and keep a running tally across the people you research.

Signal	What it proves	Points
"Great idea, I'd use that"	Nothing. It cost them nothing	0
Waitlist sign-up	Curiosity	1
A public post asking for a tool like yours	The problem is real for someone	2
A workaround they built, or someone they hired to do the job	The problem costs time	3
A named current spend ("we pay $400 a month for this")	There is a budget	4
A click on a paid plan on a real pricing page	Your price range is acceptable	4
A signed letter of intent with a price	A buyer has committed	5
A deposit, pre-order or paid pilot	They will pay	6
A second payment or renewal	They will keep paying	7

If your evidence is all zeros and ones, you don't know yet. Several fours from different companies mean the problem has a budget. A handful of sixes means you have customers. The rest of this guide is about climbing the ladder as cheaply as possible.

Step 1: Find people who already pay for the problem

Before you talk to anyone, check whether the problem already costs people money. This is the cheapest evidence there is, and most of it is public. People describe their tools, prices and frustrations on Reddit, X, LinkedIn and GitHub every day.

You are looking for four kinds of post.

Spend and switching language on Reddit

Search Reddit for the problem, then read the results for words that signal money or effort. For the reconciliation tool, a search such as "stripe quickbooks reconciliation" turns up comments like these:

• "we pay a bookkeeper to..."
• "I spend every Friday matching..."
• "is there a tool that..."
• "alternative to [competitor]" or "too expensive"
• "I'd happily pay for..."

Comments are often more useful than posts. The person asking a question rarely mentions price, but the people answering often do: "we switched from X, it was $49 a month and still missed refunds." Note the subreddit, the date and the exact words. Count distinct people, not posts, because ten complaints from one frustrated user are one data point.

Job posts for the manual version of the job

If companies are hiring someone to do the work your product would automate, the problem already has a budget line. Search LinkedIn job listings for the task, not the software: "Stripe reconciliation", "accounts receivable reconciliation", "bookkeeper for agency". Then read the responsibilities. A listing that says "reconcile Stripe payouts against invoices weekly" is a company paying a salary to solve your problem.

Job posts also help you size the market. Fifty open listings that mention the task tell you more about real demand than a top-down industry report.

Complaints about competitor pricing on X

X search accepts the operators from X's advanced search, so you can narrow results to posts with some engagement: "stripe" "quickbooks" (sync OR reconcile) min_faves:2 lang:en. Then search for "alternative to" followed by the names of the existing tools.

Posts that complain about a competitor's price are useful. They show that a paying market exists, roughly what it pays, and which part of the current offer people resent paying for.

Feature requests on open-source alternatives

If an open-source project solves part of the problem, its GitHub issues show what users want badly enough to ask for in public. Issues with long comment threads, especially from people who mention their company, point at gaps a paid product could fill. People who self-host a free tool are often price sensitive, so count this as evidence of demand, not proof of budget.

Run the searches with a script

Reading results by hand works for a first pass. Once you are running the same searches across several phrasings of a problem, a short script saves hours. This one uses the Bridgly TypeScript SDK to search Reddit comments and keep only the ones that mention money, time or a paid alternative:

// find-spend.mts — run with: BRIDGLY_API_KEY=bgly_... npx tsx find-spend.mts
import { Bridgly } from '@bridgly/sdk';

const client = new Bridgly({ apiKey: process.env.BRIDGLY_API_KEY ?? '' });

const queries = [
  'stripe quickbooks reconciliation',
  'stripe payouts quickbooks',
  'reconcile stripe fees bookkeeping',
];

// Mentions of money, time or a paid alternative.
const spendSignal =
  /\$\d|per month|a month|paying|bookkeeper|hours|alternative to/i;

for (const query of queries) {
  const res = await client.reddit.searchComments({ query, sort: 'new' });
  if (res.type === 'error') {
    console.error(`${query}: ${res.status} ${res.message}`);
    continue;
  }
  const hits = res.data.comments.filter((c) => spendSignal.test(c.body ?? ''));
  console.log(
    `\n${query}: ${hits.length} of ${res.data.comments.length} mention spend`,
  );
  for (const c of hits) {
    console.log(`- ${c.subredditPrefixed}: ${c.body?.slice(0, 120)}`);
    console.log(`  ${c.commentUrl}`);
  }
}

Each Reddit search request returns one page of results and costs 1 credit, so fifty searches cost 50 credits, about ten cents at pay-as-you-go rates. The same approach works for LinkedIn job search, X search and GitHub issue search. If you work in Claude or Cursor, the Bridgly MCP server can run these searches from a chat and summarise what it finds.

Pass threshold: a handful of people, from different companies, who describe the problem and what it costs them. Problems that people pay to solve leave a trail of complaints, workarounds and job posts. If you can't find the trail, work out why before you build.

Keep every link. Each person you found is someone you can contact in step 2.

Step 2: Interview people about what they spend today

Public posts tell you a problem exists. Interviews tell you what it costs and who pays for it. Recruit from the people you found in step 1: reply to their thread, send a direct message, or find them on LinkedIn. Someone who has complained about a problem in public is much more likely to talk about it.

Aim for 10 to 15 conversations with people who have the problem and can spend money on it. Don't pitch your idea. Ask about the last time the problem came up:

1. "Walk me through the last time you did [the task]. What happened?"
2. "What do you use for it today?"
3. "What does that cost you each month, in money or hours?"
4. "Have you tried other tools? Why did you stop using them?"
5. "If you wanted to buy something to fix this, who would sign off?"

Questions 3 and 5 matter most for willingness to pay. A named number, like "about $400 a month for a part-time bookkeeper", is a four on the ladder. "I'd have to ask my boss, and she hates new tools" tells you the sale is harder than the problem suggests.

Pass threshold: at least half the people you interview can say what the problem costs them today without you suggesting a number. If almost nobody can, the problem may be real but not worth paying to solve.

Step 3: Put a real price in front of buyers

Once you know the problem has a budget, find out whether your price fits inside it. Two methods work well together: one gives you a price range to test, the other tests it with behaviour.

Ask the four price questions

The Van Westendorp price sensitivity meter asks four questions after you have described the product:

1. At what price would it be so cheap that you'd doubt the quality?
2. At what price would it be a bargain?
3. At what price would it start to feel expensive, though you'd still consider it?
4. At what price would it be too expensive to consider?

Add these to the end of each interview. With 20 or more answers, the overlap between "a bargain" and "starting to feel expensive" shows the range most buyers accept. These are still opinions, so use them to choose a price to test, not as proof that anyone will pay.

Show the price on a real pricing page

Next, test that price with behaviour. Put up a page that states the problem, the outcome and two or three paid plans with real prices. When a visitor clicks a plan, show an honest message: the product isn't live yet, and you will hold founding-customer pricing for them if they leave an email.

Buffer's founder Joel Gascoigne ran this test in 2010. Before the product existed, he added a pricing page between the landing page and the sign-up form. Enough visitors clicked paid plans that he built it, and Buffer had its first paying customer about seven weeks after he started on the idea.

Send traffic from people who match your buyer, not from your own followers. Search or LinkedIn ads aimed at the job titles you interviewed work, as do replies to the threads you found in step 1, or a post in the subreddit where you found the complaints if its rules allow it. Measure the share of visitors who click a paid plan, and compare the plans. If nearly everyone clicks the cheapest one, the higher tiers cost more than the problem is worth to these buyers.

Step 4: Ask for a commitment

Every step so far can pass on curiosity alone. This one can't. Ask people to pay, or to sign something with a price on it, before the product exists.

Pre-orders and deposits

For a self-serve product, offer founding-customer pricing paid up front: a discounted first year, a refundable deposit, or the first month paid in advance. Say exactly what they get and when, and make refunds easy. A hosted checkout such as Stripe Payment Links takes minutes to set up, so you never handle card details yourself.

Letters of intent and paid pilots

For a B2B product with a higher price, ask the buyers you interviewed for a letter of intent. That is a one-page note saying they intend to buy at a stated price if you deliver specific features by a specific date. A paid pilot, even at a discount, is stronger. The person who signs should control the budget, not just use the tool.

How many commitments are enough?

There is no universal number. The bar rises with price, because each customer matters more and each sale takes longer. These are rules of thumb, not laws:

Price per customer	Enough evidence to start building
Under $50 a month	10 or more pre-orders or deposits from strangers
$50 to $500 a month	3 to 5 paid pilots or signed letters of intent
Over $500 a month	2 or 3 signed letters of intent from budget owners

If you ask 30 qualified people and nobody commits, that is a clear result too. If steps 1 and 2 passed, the problem is real, and something about the price, the timing or their trust in you is off. Change one of those and ask again.

Signs people won't pay

• They describe the problem but have no workaround. A problem that hurts gets patched with a spreadsheet, a freelancer or a script.
• They can't say what the problem costs them today.
• The only people excited about it are friends, followers or other founders.
• Nearly everyone clicks the cheapest plan or the free one.
• The person who loves it can't buy it and can't name who would.
• The problem comes up a few times a year. Rare problems seldom justify a subscription.
• They ask when it launches but won't put down a deposit.

A two-week plan

Days	What to do	Evidence to keep
1–2	Search Reddit, X, LinkedIn jobs and GitHub issues for the problem	Links to posts and listings that mention spend or workarounds
3–7	Interview 10 to 15 of the people you found	What each person spends today and who approves purchases
6–8	Ask the four price questions and draft a pricing page	A price range to test
8–12	Send targeted visitors to the pricing page	The click rate on each paid plan
10–14	Ask interviewees and plan clickers for a pre-order, deposit or letter	Payments and signed letters

At the end you have an evidence file instead of a feeling. Score it on the ladder and decide: build, change the price or audience and run steps 3 and 4 again, or move on to the next idea.

Frequently asked questions

Is a waitlist enough to prove people will pay?

No. Joining a waitlist costs nothing, so it only shows curiosity. Treat the waitlist as a list of people to interview and to ask for a deposit, and build once some of them pay.

How can I test willingness to pay without an audience?

Start with the people who have already posted about the problem on Reddit, X, LinkedIn or GitHub. They are your first interviewees, and replying to them is free. Ads aimed at the job titles you interviewed can then fill a pricing page test without any followers of your own.

What if competitors already charge for this?

That is good news for demand, because a competitor with paying customers proves the budget exists. Your research shifts to why people would switch. Read complaints about the competitor's price, missing features and support, and test whether your offer answers them.

Should I offer a free plan while validating?

Not while you are testing price. A free plan lets people say yes without telling you anything about what they would pay. You can add one later if it helps you acquire customers.

How long does it take to know if people will pay?

Two to four weeks of focused work usually gives a clear answer for one idea and one type of customer. If it takes much longer than that to find ten people to talk to, treat that as evidence too.

Sources

• Rob Fitzpatrick, The Mom Test
• CB Insights, Why startups fail: top reasons
• Joel Gascoigne, Idea to paying customers in 7 weeks: how we did it
• SurveyMonkey, How to use the Van Westendorp price sensitivity meter
• Stripe, Payment Links documentation