How to Validate a SaaS Idea Before Building

Validate a SaaS idea before building by talking to people who already have the problem, testing one clear promise on a landing page, asking a small number of them to pay or put down a deposit, and reading what public communities already say about the workaround. The aim is not to prove the idea is good. It is to find out whether a specific person will change behaviour or spend money before you spend months coding.

TL;DR

• This guide recommends defining one narrow group of buyers and the problem they have now, not a category you find interesting.
• Run problem interviews about past behaviour. Do not pitch, and do not ask whether they would use your idea (The Mom Test, last checked 17 Oct 2026).
• This guide recommends putting one promise on one page and sending one channel of traffic to it. Measure the action, not the visits.
• Ask for a deposit or pre-order only when the scope, delivery window and refund terms are clear (Stripe Payment Links and UK Consumer Contracts Regulations, last checked 17 Oct 2026).
• Read communities for language and repeated problems, but follow their rules and do not harvest strangers into a mailing list (Reddit Rules, Hacker News guidelines and ICO guide, last checked 17 Oct 2026).
• This guide recommends writing a decision rule before you test. Build only when the evidence is consistent, or stop and narrow the idea.

Disclosure: ZeroRaised is a live launch and discovery site for solo and bootstrapped makers. This article makes no claim about its audience or results.

What does validation mean for a solo maker?#

For this guide, validation means evidence that a defined group of people will do something costly to solve the problem you want to solve. The costly thing can be time, money, a change in workflow, a conversation with a colleague, or a payment before the product exists. An opinion is not evidence. A compliment is not evidence. A signup is weak evidence until the person does something that costs them.

This guide separates that work into four questions:

1. Problem evidence. Does the problem occur often enough, and painfully enough, that people already work around it?
2. Solution evidence. Does a specific promise describe a result they recognise and want?
3. Willingness-to-pay evidence. Will someone part with money, or make a formal commitment, before the product is finished?
4. Channel evidence. Can you reach more people like them, repeatedly, without paying more than the product can support?

These are different questions, and one test rarely answers all four. A landing page can show that a promise attracts attention. It cannot show that people will pay. A pre-sale can show that a few people will pay. It cannot show that you can acquire customers at a sensible cost. Interviews can show how the problem is experienced. They cannot show that the market is large enough to build a business on.

That framing follows the customer development tradition. Steve Blank's work describes a continuous loop of hypothesis testing, experimentation through minimum viable products and adaptation through pivots (Steve Blank, Customer Development, last checked 17 Oct 2026). The Lean Startup site describes the same emphasis on rapid experimentation and validated learning (The Lean Startup, last checked 17 Oct 2026). In practice, that means testing a belief against behaviour before it becomes a roadmap.

The useful discipline is to name the riskiest assumption first. For many technical solo makers, the riskiest assumption is not "can I build it?" It is "will anyone who does not already know me care?" If that is your situation, spend your first weeks on demand, not architecture.

Why should validation come before code?#

Code feels like progress because it produces something visible. It also makes the idea harder to abandon. Once you have a schema, an authentication flow and a billing integration, every conversation becomes a defence of work you have already done. A maker who has not written code can hear "this is not a problem for me" and change course cheaply.

Paul Graham's essay on startup ideas includes a story about his own mistake: in 1995 he spent six months on a company to put art galleries online without paying attention to users, and did not notice his model of the world was wrong until he tried to convince people to pay for what he had built (Paul Graham, How to Get Startup Ideas, last checked 17 Oct 2026). The lesson is not that every idea needs a grand validation programme. It is that paying attention to users is cheaper before the code exists.

The same essay relays advice from Paul Buchheit to founders with bad ideas: go and sell the product as soon as possible, before wasting time building it. Graham says founders often learn that nobody wants what they are building, and sometimes come back with a better idea discovered during the attempt (Paul Graham, How to Get Startup Ideas, last checked 17 Oct 2026). Sell, ask, watch and read before you build.

This is not an argument for endless research. Validation is a short, deliberate phase with a decision at the end. It should produce a written answer to one question: what is the smallest build that deserves the next month of your time?

How do you run problem interviews that produce useful answers?#

A problem interview is a conversation about the other person's work, not a demonstration of your idea. A widely used reference is Rob Fitzpatrick's The Mom Test, subtitled on its site as how to talk to customers and learn if your business is a good idea "when everyone is lying to you". The site says the book covers how to avoid biased feedback and how to work out whether someone is really going to buy (The Mom Test, last checked 17 Oct 2026). The practical rule this guide takes from it: ask about their work and past behaviour, so a polite answer cannot stand in for a real problem.

Who should you interview?#

Interview people who have the problem this week. Not people who might have it one day. Not other founders who sympathise with the difficulty of building. Not friends who want to be encouraging.

Recruiting by hand is normal at this stage. Paul Graham calls manual user recruitment the most common unscalable thing founders have to do at the start, and says you cannot wait for users to come to you (Paul Graham, Do Things that Don't Scale, last checked 17 Oct 2026).

Good sources of interviewees:

• People who have posted publicly about the problem, asking for a tool or complaining about a workaround.
• People who use an adjacent product and have left a detailed review.
• Former colleagues or clients who fit the buyer profile.
• People who have paid for a service, course, freelancer or spreadsheet template that solves part of the problem.
• Trade associations, professional groups and local networks where the job is discussed.

Ask for a short conversation about how they handle the problem today. Do not ask for feedback on your idea in the first message. "I am researching how small accounting firms handle client document collection. Could I ask you about your current process?" is easier to accept than "I have built a tool, will you try it?"

For business products, separate the user from the buyer. The person who feels the pain may not control the budget. The person who controls the budget may not understand the workflow. Talk to both, and ask who else is involved when the problem occurs.

What questions should you ask?#

Ask about specific past events. The further the conversation drifts into the future, the less reliable it becomes (The Mom Test, last checked 17 Oct 2026).

A useful sequence:

1. When did this problem last come up?
2. Walk me through what happened, step by step.
3. What did you do about it?
4. How long did that take, and what did it cost?
5. What have you tried before? Why did you stop?
6. Who else was involved?
7. What would happen if you did nothing next time?
8. Have you paid for anything to make this easier?

Then follow the detail. "Can you show me the spreadsheet?" "What happened after that?" "Why did that not work?" "Who approved the purchase?" "What did you try before you bought that?" Specific follow-ups produce better material than a longer list of clever questions.

Questions to avoid:

• "Would you use a tool that does X?"
• "Do you think this is a good idea?"
• "How much would you pay for it?"
• "Wouldn't it be useful if...?"

These questions ask people to predict their own future behaviour, and they invite politeness. A person who says "I would definitely use that" has given you a social response. A person who describes the invoice they paid a freelancer to fix the problem has given you a fact (The Mom Test, last checked 17 Oct 2026).

What should you record?#

Record the exact words people use for the problem, the workaround and the outcome. Those words become your landing page headline, your onboarding copy and your search terms. Do not tidy them into your own vocabulary.

For each conversation, keep a short note with:

• The person's role and the kind of organisation they work in.
• The trigger that made the problem urgent.
• What they currently do, including tools, people and manual steps.
• What it costs in time or money, in their own description.
• What they have already tried and rejected.
• Whether they control the budget or influence it.
• The next step they agreed to, if any.

Ask permission before recording. Keep notes in one place, and do not paste identifying details into public posts. If you would not want the person to read your note, the note is probably too loose.

What are you listening for?#

You are listening for evidence of four things:

• Frequency. Does the problem happen weekly, monthly or once a year?
• Consequence. What breaks, costs money or creates risk when it happens?
• Existing spend. Has the person already paid with money, time or attention?
• Authority. Can this person choose a new tool, or only recommend one?

A problem that happens once a year and costs an hour is unlikely to support a subscription on its own. A problem that happens every week and already consumes a freelancer's time is more interesting. A problem that the user complains about but the buyer never funds is a product that will stall in procurement.

How do you avoid leading the witness?#

Do not describe your solution until the end of the conversation, and sometimes not at all. If you must describe it, do so after you have heard the current process, and then ask what would have to be true for them to switch. Watch what they do next, not what they say.

Do not argue with a negative answer. "That is interesting, why not?" is more useful than a defence of your idea. The goal of the conversation is information, not a convert.

Which validation method should you use?#

Use the cheapest method that can answer your riskiest question. The table below compares the four methods in this guide.

The sequence that usually fits a solo maker is interviews first, community research alongside them, then a landing page, then a pre-sale to the people who responded. Do not run all four at once. You will not know which one produced the result.

How many conversations are enough?#

There is no universal interview count. Start with a small batch from one narrow segment, review what changed after each conversation, and continue until additional interviews stop adding triggers, workarounds or objections. If every conversation is different, narrow the segment before continuing. This is a practical stopping rule, not a statistical threshold.

Keep a simple table with one row per conversation. Count how many people described the problem without being prompted, how many already spend money on it, and how many asked what happens next. Those counts are more useful than a feeling that the conversations went well.

Beware the false negative. A set of interviews can fail to find demand because you spoke to the wrong people, described the problem in your language rather than theirs, or chose a segment that cannot buy. Before you kill the idea, check whether the recruitment was wrong. The answer is often "wrong segment", not "no market".

How do you test demand with a landing page?#

A landing page test checks whether a promise, written for one audience, produces a specific action. It is a message test and a channel test. It is not a product test, and it is not proof that people will pay.

What should the page contain?#

One page, one audience, one problem, one promise, one action.

• Headline. The result the buyer wants, in words they recognise.
• Subhead. Who it is for and how it works, in one or two sentences.
• Three points. The mechanism, the time or cost saved, and the main objection handled.
• Proof. Only real proof. A screenshot of the actual workflow, a named testimonial with permission, or a clear statement that the product is in development.
• Price. State the price or the expected range. "Contact us" hides the most important objection until later.
• Action. A deposit, a pre-order, a pilot call, or an email signup, in descending order of strength.
• Small print. What happens next, how often you will email, and how to opt out.

Do not use invented logos, invented user counts, fake scarcity or testimonials from people who have not used the product. A page that lies to get a signup has not validated anything. It has tested whether a lie converts.

If the product does not exist yet, say so. "In development. Join the pilot and get access in March" is honest and still useful. "Start your free trial" when there is no trial wastes the visitor's time and teaches you nothing about the real offer.

Where should the traffic come from?#

Send traffic from one channel at a time so you can attribute the result. A relevant community, a search page, a newsletter, a direct outreach list or a small paid test can all work. The channel matters as much as the page. A promise that converts cold traffic is stronger evidence than a promise that converts your friends.

Do not buy a large volume of cheap traffic and call it validation. A few conversations with the right people teach more than many visits from the wrong ones. If you cannot reach enough of the right people, go back to interviews and community research.

Use a link tag or a separate page per channel so you can see where each visitor came from. Record the source on every signup and every payment.

What should you measure?#

Measure the action that costs the visitor something:

• Email signup with clear consent.
• Booking a call.
• Downloading a sample or template.
• Starting a pilot.
• Paying a deposit.

Then measure the quality of that action. How many of the signups fit the buyer profile? How many replied to your follow-up? How many booked the call? How many would accept a pre-sale offer?

Do not optimise for page views, time on page or social likes. Those numbers can rise while nothing useful happens.

Should you run an A/B test?#

Only when you have enough traffic for the difference to mean something. For most solo makers at this stage, sequential tests are more practical. Run one headline for a week, then the other, keeping the audience and channel as similar as you can. If the results are close, the headline is not your main problem. The offer or the audience probably is.

Do not change five things at once. You will not know what caused the change, and you will be tempted to believe the most flattering explanation.

Should you ask for money before the product exists?#

Yes, if you can describe exactly what the buyer will get, when they will get it, and what happens if you miss the date. A pre-sale is one strong form of evidence because it turns stated interest into a financial commitment. It is also an obligation, so treat it as one.

Selling before building is not a licence to take money for a vague promise. The offer has to be concrete enough that a buyer can make an informed decision.

What should a pre-sale offer include?#

• The exact problem and outcome, not a list of features.
• Who it is for, and who it is not for.
• What is included in the first version.
• The delivery window, with a specific month or date range.
• The price, and whether it is a deposit or the full amount.
• What happens if delivery is late.
• The refund policy, in plain language.
• How support will work during the first months.
• What you will do with their data.

Put those terms on the page before the payment button. Do not bury them in a checkout flow.

A payment link is enough to start. Stripe's documentation describes Payment Links as a way to accept payments online without writing code, with guides for creating, sharing and tracking a link (Stripe Payment Links, last checked 17 Oct 2026). You do not need a full checkout, a customer portal or a billing system to test whether someone will pay, though it helps to check what the provider keeps on your test price. You do need a record of what you promised.

What does the law require?#

This depends on where you and your buyers are. In the United Kingdom, the Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 set out information and cancellation rules for distance contracts (legislation.gov.uk, last checked 17 Oct 2026). If you take money from consumers before delivery, check how those rules apply to your offer, including the information you must give before the purchase and the cancellation rights that follow.

For business buyers, the rules and expectations are different, but the commercial obligation is the same: deliver what you described, or refund. Check the terms of your payment processor. Keep records of sales for tax and accounting. If you are unsure, get advice for your jurisdiction rather than copying a template from another country.

What counts as a useful pre-sale result?#

Record:

• How many qualified people saw the offer.
• How many paid.
• How many asked a question and then did not pay.
• The objections you heard most often.
• The source of each buyer.
• Whether anyone asked for a refund or a change to the terms.

A small number of buyers from a defined set of qualified conversations is a signal worth investigating. It is not a business yet. The next question is whether you can find more people like them through a channel you can repeat, and whether the first buyers stay after delivery.

If nobody pays, do not immediately conclude that the idea is dead. Check the offer. Was the outcome specific? Was the price plausible? Was the buyer asked to trust a stranger with no proof? Did the page explain what happens if delivery slips? Interview the people who declined. Their reasons are the next test.

What about letters of intent?#

For this guide's evidence ladder, a signed letter of intent or pilot agreement is more useful than an unrecorded expression of interest, although it is not a payment. It can be useful in business sales when procurement cannot pay before a security review. Treat it as a commitment with conditions, and write down the conditions. If the buyer will not sign a short letter that states the problem, the scope and the expected budget, the enthusiasm may be social rather than commercial.

How do you research a community without becoming a nuisance?#

Communities are useful for two things: the language people use, and the frequency of the problem. They are not a free focus group, and they are not a lead list.

Start by reading. Search for the problem in the community's own search, then search the wider web for the same phrases. Read old threads, including the ones that ended without a solution. Note the words people use for the workflow, the tools they recommend and the workarounds they describe. An old thread is still evidence about how people talked then, but check whether the available tools have changed.

This is one part of market research, not the whole of it. The US Small Business Administration says market research helps you find customers, and its competitive analysis guidance lists factors to assess, including competitors' strengths and weaknesses and your window of opportunity to enter the market (SBA, Market research and competitive analysis, last checked 17 Oct 2026). A community thread can tell you what people say. It cannot tell you whether they buy, or what a competitor's contract terms are.

Read the rules before you post. Reddit's site-wide rules say to abide by community rules, participate authentically in communities where you have a personal interest, and not spam or engage in disruptive behaviour, including content manipulation (Reddit Rules, last checked 17 Oct 2026). The Hacker News guidelines say it is fine to post your own stuff part of the time, but the primary use of the site should be for curiosity, and they ask people not to solicit upvotes, comments or submissions (Hacker News guidelines, last checked 17 Oct 2026). Those rules apply to research posts too. A question asked only to harvest leads is still promotion.

A method that respects the room:

1. Join and read before posting anything.
2. Answer other people's questions without mentioning your product.
3. Ask the moderators whether a research question is allowed.
4. Post one specific question, in the community's language, and say what you are trying to learn.
5. Disclose that you are building something in the space.
6. Reply to everyone, and do not move the conversation to a sales pitch unless they ask.

Do not copy the same post into several communities. Do not send direct messages to everyone who posted about the problem. In the United Kingdom, the ICO says you must not send marketing emails or texts to individuals without specific consent, with a limited exception, the soft opt-in, for your own previous customers (ICO guide to PECR, last checked 17 Oct 2026). A public complaint is not consent to be marketed to.

Community research has a bias problem. The people who post are the ones with time, confidence and a strong opinion. They may be early adopters, or they may be the customers who churned from a competitor. Use their language, but do not treat their preferences as the market's preferences. Test the pattern in interviews and in a paid offer.

Competitor reviews are a useful source of community language and reported problems. Read the one-star and three-star reviews of the tools people already use. Look for the same complaint repeated across different products. That complaint is a gap, but it is not automatically your opportunity. Check whether the incumbent has chosen not to fix it for a commercial reason.

What evidence should you keep?#

Keep a decision log from the first day. It can be a single document with one row per test.

The threshold matters more than the result. "We will build if five qualified people pay a deposit" is a decision rule. "We will build if the feedback is positive" is not. Write the rule before you run the test, when you are still able to be honest with yourself.

Keep interview notes with the person's own phrases. Keep a list of everyone who asked to hear more, with the source and the date. Keep a record of every payment and every promise you made. Keep the landing page copy that produced each result, because the page will change and you will forget what it said.

Do not keep personal data you do not need. If you collect emails, say what you will send and how often. Give people a way to leave the list. If you are handling customer data during a pilot, write down where it lives and who can see it.

At the end of the validation phase, write a one-page memo:

• Who the buyer is, in one sentence.
• The problem and the current workaround.
• The evidence you have, with counts and sources.
• The offer and price you tested.
• The channel you used to reach people.
• The biggest remaining risk.
• The smallest build that would test it.
• The conditions under which you would stop.

Show the memo to someone who will disagree with you. Ask what evidence would change their mind. If you cannot answer, you are not ready to build.

What does a four-week validation sprint look like?#

This is a sequence for one person working alone. It is not a promise that four weeks is enough for every market. Business sales with long procurement cycles will take longer. Consumer products with cheap traffic may move faster, but the evidence bar should not move with them. The schedule and workloads below are an editorial planning example, not a research benchmark.

The order matters. Do not build the landing page before you have heard the problem described. You will fill it with your assumptions. Do not offer a pre-sale before you can state the delivery window. You will create an obligation you cannot meet.

If week one produces no conversations, do not move to week three and call a page with no traffic a test. Fix recruitment first. If week two produces interviews but no pattern, narrow the segment. If week three produces visits but no qualified action, change the promise or the channel before you change the product.

When should you stop validating and start building?#

Build when four things are true:

1. You can name a specific buyer and the trigger that makes the problem urgent.
2. Several people in that group described the same problem and the same current workaround without prompting.
3. A clear promise produced a qualified action, and at least some people paid or made a formal commitment.
4. You can reach more of those buyers through a channel that is not a one-off favour.

You do not need certainty. Validation reduces risk; it does not remove it. You will still be wrong about retention, support load, pricing and the features people actually use. The point is to be wrong about smaller things, later, after you have earned the right to learn from real usage.

Build the smallest thing that delivers the promise. If the promise is "collect client documents in one place", do not build a document management platform. Build the collection flow, the reminder and the export. If the promise is "a weekly report your client will read", build the report before you build the dashboard.

Keep the validation evidence. When a customer asks for a feature, compare the request with the problem you validated. When a competitor launches something, compare it with the buyer you chose.

What mistakes make validation worthless?#

• Interviewing friends and other founders. They are kind, and they are not the buyer.
• Pitching instead of asking. You learn whether people are polite, not whether they have the problem.
• Counting a waitlist as demand. An email address is interest in a promise, not a purchase.
• Using fake proof. Invented logos and testimonials poison the result and the reputation.
• Testing with the wrong traffic. Cheap, broad traffic will make a specific offer look weak.
• Asking "would you pay?" Ask what they have already paid for, and then ask for a real commitment.
• Taking pre-orders without terms. A delivery date and a refund path are part of the offer, not paperwork.
• Spamming communities. You will lose the room and learn nothing.
• Ignoring consent and privacy. A public post is not permission to add someone to your list.
• Treating one enthusiastic buyer as a market. One buyer is a case, not a pattern.
• Validating forever. Research without a decision is procrastination with notes.
• Confusing interest with urgency. "That sounds useful" and "I need this before Friday" are different problems.

Where does ZeroRaised fit?#

Validation happens before launch. Once you have a product people can try, ZeroRaised is a launch board for solo and bootstrapped makers with no institutional VC or accelerator equity. The home page shows the current board and explains the funding rule, and the submit page is the submission entry point. The home page states that submitting is free and that launches go live at 00:01 PT, with votes closing at midnight PT.

If your budget is tight, the perks page lists public free tiers, credits and discounts from tools that support independent makers. It links to each vendor's own terms rather than quoting limits that change. The Complete Product Launch Checklist for Bootstrapped Makers covers what to prepare before you submit, and Where to Launch a SaaS in 2026 helps choose a venue once the product is usable.

If you are still deciding how to fund the build, 8 Ways to Fund a Software Product Without Venture Capital sets out the trade-offs of each route. When the first users arrive, How to Get Your First 100 Users for a Bootstrapped Product picks up where validation stops.

After an AI-assisted build ships, use the vibe coded app marketing guide for distribution and the vibe coded app security checklist for release checks.

When the validated offer needs a permanent public address, use the business domain name guide before registration.

Sources#

• The Mom Test, Rob Fitzpatrick, last checked 17 Oct 2026
• Paul Graham, How to Get Startup Ideas, last checked 17 Oct 2026
• Paul Graham, Do Things that Don't Scale, last checked 17 Oct 2026
• Steve Blank, Customer Development, last checked 17 Oct 2026
• The Lean Startup, last checked 17 Oct 2026
• US Small Business Administration, Plan your business: market research and competitive analysis, last checked 17 Oct 2026
• Stripe Payment Links, last checked 17 Oct 2026
• The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, last checked 17 Oct 2026
• Reddit Rules, last checked 17 Oct 2026
• Hacker News guidelines, last checked 17 Oct 2026
• ICO guide to PECR, electronic mail marketing, last checked 17 Oct 2026