How to Validate a SaaS Idea Before Writing Any Code

To validate a SaaS idea, you collect evidence that a specific group of customers has the problem and will pay to have it solved, before anyone writes code. The cheapest route is to interview potential customers, put a price on a simple landing page, ask for payment upfront and deliver the solution by hand to your first few customers. Each step costs a little more than the one before and tells you more.

I'm a developer who makes a living building software, so telling you to wait might sound odd. But a finished SaaS that nobody pays for is a mistake no developer can fix afterwards.

The short answer: four methods from cheapest to strongest

The rule is simple: move to the next method once the current one gives you a clear yes, and stop when you get a clear no. You don't need all four. A B2B idea can be validated with one round of interviews and three signed pilot agreements.

Validation is step 2 in my guide to building a SaaS from idea to paying customers, and this post covers that step in depth.

What counts as evidence

Most ideas don't get validated. They get confirmed. You pitch the idea, people are polite and say it sounds interesting, and you walk away feeling good with no evidence at all.

I think of signals as a ladder. The more a signal costs the customer, the more it's worth:

1. Praise and interest ("that sounds clever"). Worth almost nothing.
2. An email address on a waitlist. Worth a little, more so if the price was on the page.
3. Time: an hour for a follow-up call or to try a prototype.
4. Reputation: they introduce you to their manager or a colleague. Now they have something at stake.
5. Money or a signature: a pre-payment, a paid pilot or a letter of intent.

Surveys and social media likes sit at the bottom of the ladder. People answer based on what they think they would do, which is not the same as what they do when it's time to pay.

Validation also isn't permanent. You're testing an assumption about a specific customer group, a specific problem and a specific price. Change any of the three and you need to test again.

How to validate a SaaS idea in six steps

You can skip a step when the answer is already obvious, but don't start with step 6.

1. Write your hypothesis in one sentence

State who the customer is, what problem they have and what they'd pay to make it go away. For example: "Practice managers at small dental clinics spend several hours a week calling patients about canceled appointments and would pay €60 a month to have it automated."

The sentence forces you to pick one customer type and put a number on it. Both feel uncomfortable, which is exactly the point. If you're unsure how to structure the price, I've covered the most common SaaS pricing models separately.

Also write down what would make you drop the idea.

2. Find 10-15 people who have the problem

Not friends, family or other founders. You need people who have the problem today and could realistically become paying customers. For B2B, you'll usually find them through LinkedIn, industry associations, online communities for their profession or your own network in the industry.

If you can't find 10-15 of them in a couple of weeks, that's a finding in itself. In a small market like Denmark or Norway, a narrow niche runs out of people fast. Then either the market is too small, or you need to test in more than one country from the start.

3. Ask about the problem, not your idea

Ask what they do today, not what they would do. Good questions are concrete and about things that have already happened:

• When did this last happen, and what did you do?
• What do you use today, and what does it cost you in time or money?
• What have you already tried to fix it?

Avoid questions like "Would you use a tool that...?" The answer is almost always yes, and it commits nobody to anything. Rob Fitzpatrick's The Mom Test is a short, practical book on asking questions that get honest answers, even from people who want to be nice to you.

Notice whether they bring up the problem on their own, and whether they already pay for a poor workaround. A spreadsheet that three employees maintain by hand is a better sign than enthusiasm.

4. Put up a landing page with a price

A landing page describes the product as if it already existed: who it's for, what problem it solves and what it costs. The button leads to a waitlist or a form to book a demo. You can build one with a no-code tool in a day or two.

The price has to be on the page. Without it, you're measuring curiosity, not buying intent. Send people from your target group to the page, through the contacts you found in step 2, relevant communities or a small ad campaign, and track how many sign up.

A landing page tells you the most about self-serve products with many small customers. For higher-priced B2B software it says less, because those buyers rarely join waitlists. That's where step 5 matters more.

5. Ask for money or a signature

This is the step most founders skip, and it's the one that matters most. Offer your most interested contacts a place as a pilot customer: a discount on the first year in exchange for paying upfront, or a paid pilot period once version one is ready.

You don't need code to take payments. Stripe Payment Links are set up in the Stripe dashboard and handle both one-off payments and subscriptions. Many European B2B buyers prefer to pay by invoice, so an invoice for a paid pilot or a signed letter of intent is often more realistic than asking for a card.

When someone says no to paying, ask why. That answer is often worth more than ten waitlist sign-ups.

Don't promise more than you can deliver. If you take money, you need a rough idea of what version one will cost and how long it will take, and customers should get a refund if the product never ships. Have a lawyer look at your terms if you're unsure.

6. Deliver it by hand to your first customers

A manual MVP, also called a concierge MVP, means you do the work the software will eventually do. The customer pays for the outcome, and behind the scenes it's you with a spreadsheet, an inbox and a calendar.

It's inefficient on purpose. You learn exactly which steps customers go through, what they ask about and what should be automated first. Paul Graham describes the principle in his essay Do Things that Don't Scale, including how Stripe's founders set the product up for their first users themselves.

A manual MVP is still an MVP. The only difference is that the code is missing. If the term is new to you, I've written about what an MVP is and what it isn't.

When you can no longer keep up manually and customers are still paying, that's a good time to start building.

How to tell whether your idea passed

Set your thresholds before you start, not after. Otherwise you'll end up calling 40 sign-ups a success because it took you three months to get them.

Start with the math. If your product costs €50 a month and needs to bring in €2,500 a month before it's worth your time, you need 50 customers. Ask yourself whether your test shows a realistic path to those 50.

I sort the outcome into three groups:

• Continue: several people have paid or signed, and the interviews point to the same problem.
• Adjust: people have the problem but won't pay your price, or a different customer type turns out to be more interested. Change one thing and test again.
• Stop: you can't find people with the problem, or nobody will pay, even after an adjustment.

There's no fixed number of sign-ups or pre-payments that counts as enough. It depends on your price and how many customers you need. In my view, though, two paying pilot customers for B2B software are a much stronger signal than a few hundred email addresses from a page with no price on it.

The methods I'd use myself

If the idea were mine, I'd pick the method based on who the customer is:

• Higher-priced software for businesses: interviews and pilot agreements. I'd skip the ads and use the landing page only as something to send after a call.
• Self-serve for many small customers: a landing page with a price and a small ad campaign aimed at exactly that audience, followed by pre-sales to the people who sign up.
• An idea where the workflow is unclear: manual delivery. You won't figure out what the software should do by guessing. You figure it out by doing the work yourself.

If you're building for Europe, validate in the market you'll launch in. A scheduling tool for Danish clinics and one for German clinics aren't quite the same product: language, buying habits, local rules and the systems customers already use all differ. A yes in one country tells you less about the next one than you'd hope.

It can be tempting to jump straight into the code. It's the part that feels like progress. But a few weeks of conversations can save you months of building something that has to be redone.

AI tools like Lovable and Bolt are fine for a clickable prototype to show in interviews. Just don't let real customers and personal data into it without a proper review.

When validation isn't enough, and when not to hire me

Validation tests whether people will pay. It doesn't test whether the product can be built. If the risk in your idea is technical, such as an integration with a system that has no public API or calculations that must be exactly right, a small technical proof of concept is the right next step. A developer can help with that, usually as part of a discovery phase.

There are also situations where you don't need a developer like me yet:

• You haven't talked to customers. Spend your money finding them, not on code.
• A spreadsheet, a form and a payment link can handle your first customers. Run it that way until the manual work starts costing you customers or sleep.
• You want a developer to validate the idea by building it. That's the most expensive market research there is.

The price gap is large. A SaaS MVP with subscriptions and user roles typically lands around €25,000-40,000 with an experienced freelancer, as I break down in my MVP development cost guide. Validation costs a fraction of that.

Next steps: from validated idea to a realistic quote

Once you have a clear yes from real customers, the next step is to scope version one and get a price for it. Run through this checklist before you contact a developer.

If you can tick most of these, you're ready to define the first version. My guide on how to scope an MVP walks you through it. And if you want to know what the next stage costs, see how I price discovery and development.

Frequently asked questions

Will someone steal my SaaS idea if I talk about it?+

It rarely happens, and the risk is smaller than the risk of building in secret. An idea is worth little until someone executes it, and the people you interview are busy running their own businesses. If you're sharing details with a developer or a partner, an NDA can be reasonable. Potential customers rarely sign one, so don't ask them to.

Is it legal to take payment for software that doesn't exist yet?+

Yes, pre-selling is common, but you need to be clear about what the customer is buying and when it's expected to be delivered. Put the terms in writing, including what happens if the product is delayed or never ships, and refund the money in that case. Consumer protection rules in the EU are stricter than the rules for selling to businesses. Have a lawyer review your terms before you send the first payment link.

Can I validate my idea with a survey?+

A survey can help you find out who has the problem, but it can't show that anyone will pay. Use it to find the people you should talk to instead. End it with a question asking whether they'd join a 20-minute call. Those who say yes are your best candidates for pilot customers.

How long does it take to validate a SaaS idea?+

Usually a few weeks to a few months. Interviews and a landing page can be done in 2-4 weeks if you can reach your target group. Pre-selling to businesses takes longer, because purchases need sign-off. If you've spent three months without a clear signal either way, that's an answer in itself: the market is hard to reach, or the problem isn't painful enough.