How to Test a SaaS Idea Before Coding

Writing SaaS code before you know a business will pay for it is one of the most expensive mistakes a founder can make. B2B sales cycles are slow, budgets are scrutinized, and a mildly interested prospect in an interview can turn out to be nowhere near ready to buy once a real invoice is on the table.

Testing a SaaS idea before coding means working through a sequence of steps that each ask for a bigger commitment than the last — starting with a conversation and ending, ideally, with a signed pilot agreement or purchase order, all before your engineering team writes a line of production code.

Step 1: Structured Customer Interviews

Start with 10-20 conversations with people who would actually buy and use the product — not friends in adjacent roles, but the specific buyer persona and, separately, the day-to-day user if they differ.

Ask about their current process, what tool or spreadsheet they use today, how much time or money that process costs them, and what they’ve already tried to fix it. Avoid pitching your idea in this step. The goal is to learn whether the problem is painful and specific enough that people are already spending effort or budget on it.

If most conversations reveal a mild inconvenience rather than a real cost, that’s a signal to refine the idea before moving forward, not to push ahead on optimism.

Step 2: Build Demo-ware, Not a Working Product

Once the problem is confirmed, build a clickable prototype — sometimes called demo-ware — using a design tool like Figma or a no-code interface builder. It should look and feel like the real product through the core workflow, but nothing behind the buttons actually needs to function.

Walk 5-10 of your interviewees through it and watch their reactions closely. Do they ask when they can start using it? Do they ask what it costs? Do they point out a missing step that would stop them from adopting it? A prototype that generates specific, practical questions (“does this integrate with our CRM?”) is a stronger signal than one that only gets polite praise.

Step 3: Move to Pre-Sales Conversations

With a validated prototype, start explicit pre-sales conversations. Present pricing, ask directly whether they’d sign up at that price, and see how they respond to a real number rather than a hypothetical one.

This is where letters of intent (LOIs) become useful. An LOI is a short, non-binding document where a prospective customer states their intent to buy or trial the product once it exists, often with rough terms like expected seat count or budget range. Businesses that are only mildly curious rarely bother signing one — those that do are telling you something real about urgency.

Collecting three to five LOIs from qualified target customers is a far stronger foundation for a build decision than thirty encouraging but non-committal conversations.

Step 4: Secure a Paid Pilot or Beta Agreement

The strongest pre-code signal in SaaS is a signed pilot or beta agreement, ideally with some form of payment attached — even a heavily discounted founding-customer rate. This tells you three things at once: the customer has budget authority, the timing is right for them, and they’re willing to put a small amount of money behind the outcome before the product fully exists.

A pilot agreement can also specify what “success” looks like for that customer in concrete terms — a workflow completed, a report generated, hours saved per week — which becomes your MVP’s core scope rather than a wish list of features.

Stage	What You’re Testing	Typical Commitment
Customer interviews	Is the problem real and costly?	Time only
Clickable prototype (demo-ware)	Does the proposed solution resonate?	Attention, specific feedback
Pre-sales conversation + LOI	Will they commit once it exists?	Written, non-binding intent
Paid pilot / beta agreement	Will they pay before it’s fully built?	Money or signed contract

Why the Sequence Matters

Skipping steps is the most common mistake. Founders who go straight from an idea to building a prototype often build something nobody asked for, because they never confirmed the problem in step one. Founders who go straight to asking for money without a prototype often struggle to get a clear yes, because the prospect can’t picture what they’re agreeing to.

Each step in this sequence is deliberately designed to de-risk the next one — you don’t build demo-ware until interviews confirm the problem, and you don’t ask for a pilot agreement until the demo-ware has been tested with real prospects.

This process is a more B2B-specific version of the general approach covered in how to test demand before building an app, and it complements a broader look at how to test demand for a software product if you’re comparing which validation method fits your situation. If your SaaS idea is in the legal-tech space specifically, the same sequence applies closely in validating a contract management SaaS idea.

Eric Ries’s lean startup framework, built around the idea of testing assumptions with the smallest possible experiment before committing resources, is a useful mental model to apply at each of these four stages.

From Signed Pilot to Scoped MVP

A signed pilot agreement doesn’t mean you should build everything the customer eventually asks for. It gives you a concrete, committed first customer whose defined success criteria becomes the scope of your MVP — the smallest version of the product that fulfills what you promised in that agreement.

Turn Pipeline Signal Into a Real Product

Testing a SaaS idea before coding replaces guesswork with a sequence of increasingly concrete commitments from the people who would actually buy it. By the time you’re ready to build, you already know who your first customers are.

Frequently Asked Questions

What is the first step in testing a SaaS idea before coding?

Structured interviews with your target business buyers, focused on how they currently solve the problem and what they already pay for. This step tells you whether the problem is worth solving before you invest in a demo or prototype.

What is demo-ware and why does it matter for SaaS validation?

Demo-ware is a clickable, non-functional prototype that looks like a working product but has no backend logic. It lets you show prospects exactly what you plan to build and gauge their reaction, including whether they'd pay for it, without writing production code.

What is a letter of intent and why would a B2B customer sign one?

A letter of intent (LOI) is a non-binding written statement from a business customer saying they intend to buy or pilot your product once it's available, often with rough terms attached. Businesses sign them when the problem is painful and specific enough that they want early access or influence over the roadmap, even though it commits them to nothing legally binding.

Should I charge for a SaaS pilot before the product is fully built?

Where possible, yes, even a token amount. A paid pilot, even a discounted one, filters out prospects who are just being polite from those who have a genuine budget and urgency, and it gives you real usage data from a live customer rather than a hypothetical one.

How many pre-sales or LOIs do I need before building a SaaS MVP?

There is no fixed number, but a handful of committed prospects — whether through LOIs, deposits, or a signed pilot agreement — is far more convincing than dozens of casual positive conversations. Focus on quality of commitment over volume of interest.