How to Validate a SaaS Idea Before Writing Code

On this page

1. Start with the problem, not the product
2. Define who uses it and who pays
3. Map the alternatives honestly
4. List your feature assumptions
5. Form pricing hypotheses early
6. Interview before you build
7. Run a landing-page test
8. Test a prototype, not a product
9. Use AI-simulated testing to surface adoption objections
10. Decide what counts as a pass
11. Your next step

Software is tempting to build first and validate later, because building feels like progress. But the expensive surprises in SaaS rarely come from the code. They come from a problem that isn’t painful enough, a buyer who isn’t the user, a spreadsheet that already works well enough, or a price nobody wants to put on a company card.

This guide gives you a sequence for checking those risks before you write production code. Each step is cheap, and each one either strengthens the idea or changes it while change is still easy.

Start with the problem, not the product

Write the problem in one sentence without mentioning your solution. “Small agencies lose billable hours because time tracking happens at the end of the week from memory” is a problem. “An AI time tracker for agencies” is a product.

Then look for evidence the problem is real and recurring:

• Frequency. Does it happen daily, weekly, or once a year? Rare problems make for weak subscriptions.
• Cost. What does it cost in time, money or stress when it happens?
• Workarounds. Are people already patching it with spreadsheets, reminders or a junior employee? A workaround is a strong sign of real pain.

If you can’t find anyone with a workaround, the problem may be one people notice but don’t care enough to fix.

Define who uses it and who pays

In SaaS, the person who feels the problem is often not the person who pays. An agency designer suffers from bad time tracking; the agency owner approves the subscription; an operations lead may have to set it up.

For each role, write down what they care about. The designer wants less friction. The owner wants recovered revenue. The ops lead wants something that won’t break the existing invoicing setup. Your idea has to make sense to all three, or it stalls somewhere between the trial and the purchase.

Narrow the first audience as much as you can. “Agencies” is too broad. “Design agencies of five to twenty people that bill hourly” gives you people you can actually find and talk to.

Map the alternatives honestly

List what people do today instead of buying software:

• doing nothing and accepting the loss,
• a spreadsheet or shared document,
• a general-purpose tool they already pay for,
• a manual process someone owns.

For each, ask what it costs the customer to switch to you. Switching from “nothing” is easy but there’s no urgency. Switching from a tool the whole team already uses is hard even if yours is better. Our guide to finding customer objections goes deeper on the “we already have something” reaction.

List your feature assumptions

Every feature you plan rests on an assumption. Write them out:

Rank the assumptions by how badly the idea fails if they’re wrong. The automatic tracking assumption above is critical: if designers refuse background tracking, the product has no core.

Form pricing hypotheses early

Don’t wait until launch to think about price. Write a hypothesis: “Agencies of this size will pay a monthly fee per seat because recovered hours easily exceed the cost.” Then note what would disprove it.

Useful questions for interviews include what they pay for comparable tools, who approves new software and up to what amount, and whether they’d prefer per-seat or flat pricing. Treat answers as directional; stated willingness to pay often differs from what people actually pay. Our guide to testing startup pricing covers how to get closer to real numbers.

Interview before you build

Aim for five to ten conversations with people in your narrow audience as a rule of thumb, more if answers keep surprising you. Ask about past behavior, not hypothetical futures:

• “Walk me through how you tracked time last week.”
• “When did missing hours last cost you money?”
• “What have you tried to fix it? Why did you stop?”

Avoid describing your product until the end, if at all. The moment you pitch, people start being polite. Our guide on writing customer discovery questions has more examples.

Run a landing-page test

A landing page turns stated interest into an observable action. Describe the problem, the outcome and the price, and offer one clear next step: join a waitlist, book a demo, or request early access.

A few practical tips:

• Put the price on the page, even as “planned pricing.” Interest without a price is weak evidence.
• Send traffic from where your audience actually is: a relevant community, a newsletter, or a small, targeted ad budget.
• Measure what people do. Sign-ups and demo requests matter; page views don’t.

If the page draws visits but no sign-ups, the problem may be real but your framing isn’t landing. Test the headline before blaming the idea.

Test a prototype, not a product

A clickable mockup, a screen recording, or a “concierge” version where you do the work by hand behind a simple form can reveal whether people understand and value the workflow.

Imagine the agency time tracker. Instead of building automatic capture, you could ask three agencies to send you a weekly calendar export, and you return a summary of likely unbilled hours. If owners act on those summaries and ask for more, you’ve learned something no mockup can tell you. If they ignore them, you’ve saved months.

Use AI-simulated testing to surface adoption objections

Before or between real interviews, an AI-simulated audience can help you anticipate why people might not adopt. In a SellTo.us app or software test, each simulated user gives one of three answers (would try, maybe or wouldn’t try) plus a short reason, and the report summarizes the main reasons people hold back and shows results for each audience group.

That’s useful for questions like:

• Which objections come up repeatedly: privacy, setup effort, “we already use a spreadsheet”?
• Does one audience group react much more coolly than the others?
• Does a reworded description or a different price draw more favorable simulated answers?

Keep the limits in view. The participants are AI personas, not real people. Their answers are simulated willingness to try, not sign-ups or a forecast. They don’t see your website or competitors, and they can be more or less generous than real users. Use the objections as a list of things to check in interviews and on your landing page. You can read more on the app idea testing page.

Decide what counts as a pass

Before you start, write down what evidence would make you build and what would make you stop or pivot. For example:

• Build: several interviewees describe a costly workaround, a meaningful number of landing-page visitors join the waitlist with the price shown, and at least a few prototype users ask when they can pay.
• Rethink: people agree the problem exists but nobody has tried to fix it, or interest disappears once price appears.

Setting the bar in advance stops you from reading every result as encouraging.

Your next step

Write your problem sentence and your three riskiest assumptions today, then book your first three interviews this week. If you want a quick read on likely adoption objections before those calls, run a free simulated test (your first 1,000-participant test is free if eligible) and take the strongest objections into your conversations as questions, not conclusions.

Written by the SellTo.us Team. Examples in this article are hypothetical. SellTo.us results come from AI-simulated participants, not real people, and don’t predict sales or guarantee success.