The short answer
Validate a software idea by confirming that real people have the problem, will pay to solve it, and prefer your proposed solution over what they currently use. You do not need a working product to get those answers. A combination of customer interviews, a landing page, and a manual proof-of-concept can give you enough signal in two to four weeks to decide whether building is worth the investment.
Why most founders skip this step
Validation feels slow when you have a clear picture of the product in your head. The temptation is to move straight to development, especially now that building is faster and cheaper than it was five years ago. But speed of building is irrelevant if you are building the wrong thing. Founders who skip validation tend to discover the gap between their assumptions and reality only after spending five figures on code they cannot repurpose.
The goal of validation is not to prove you are right. The goal is to find out where you are wrong before that discovery becomes expensive.
Step 1: Write down your assumptions explicitly
Before you talk to anyone or build anything, list every belief the business depends on. Not vague ones like "people want better project management." Specific ones:
- Solo consultants with three to ten clients spend more than two hours a week on invoice follow-up.
- They would pay at least $30 a month to eliminate that task.
- They prefer a standalone tool over adding another feature to their existing accounting software.
Each assumption is a testable claim. The most dangerous ones are the assumptions you hold so firmly that you forget they are assumptions.
Prioritize them by asking: if this assumption is wrong, does the business still work? Start testing the ones where the answer is no.
Step 2: Talk to the people who have the problem
Customer interviews are the fastest way to stress-test your assumptions before spending anything on development.
Aim for ten to fifteen conversations with people who match your target profile. Recruit through LinkedIn, relevant Slack communities, Reddit threads, or your own network. Offer a 20-minute call. Most people will talk if you frame it as research rather than a sales pitch.
What to ask:
- Walk me through the last time you dealt with [the problem]. What did you actually do?
- What have you already tried to fix it? What was frustrating about those options?
- How much time or money does this cost you in a typical month?
- If you could wave a wand and fix it, what would that look like?
Avoid describing your solution until the end, if at all. You want to hear how they describe their problem in their own words, not have them react to your framing.
After ten conversations, patterns will surface. If fewer than seven of those people describe the problem the same way, your target definition probably needs narrowing.
Step 3: Test willingness to pay before writing a spec
People saying they have a problem is not the same as people paying to solve it. You need a signal of financial intent.
The most reliable low-cost methods:
Pre-sales. Describe the product clearly and ask for a deposit or a paid early-access slot. Even $50 from five people tells you more than 500 survey responses.
Waitlist with a reason to join. A landing page that explains the product and asks for an email in exchange for founding member pricing. The conversion rate on that page is data. Five percent or higher is a reasonable signal of interest; below two percent, the positioning or audience is probably off.
A manual service. Do the job your software would do, by hand, and charge for it. If someone pays you $200 for a manual process that your app would automate, you have confirmed both demand and price tolerance. This approach also teaches you exactly what the software needs to do.
Step 4: Build the smallest possible proof of concept
Once you have verbal demand and at least some financial signal, build the minimum that lets you test the core value proposition. Not the full product. One workflow, done well.
For most non-technical founders, this means choosing between:
| Option | Speed | Cost | Best for |
|---|---|---|---|
| No-code tool (Glide, Softr, Bubble) | Fast | Low | Simple data apps, directories, internal tools |
| Manual + spreadsheet + Zapier | Fastest | Near zero | Process automation concepts |
| AI-assisted dev service | Fast | Low-medium | Custom logic that no-code can't handle |
| Freelance developer | Slower | Variable | Specific technical requirements |
The right choice depends on what you need to test. If the core value is a unique algorithm or proprietary workflow, a no-code prototype may not represent the real product well enough. If the core value is a smoother user experience around a standard process, a no-code build can answer the question.
When you reach the point of commissioning actual development, understand exactly what you are buying. The article What Is Included in a Software Dev Quote? breaks down what line items should appear in any proposal and what their absence signals.
Step 5: Run one structured experiment
Validation is not a vibe. Frame it as an experiment with a clear success criterion before you start.
Example: "If 20 people see this landing page and three of them sign up for a paid pilot within two weeks, we proceed to build."
Set the number in advance. Founders who skip this step move the goalposts after the fact, counting modest results as confirmation because they are already committed emotionally.
Document what you tested, what you predicted, and what actually happened. That record becomes the foundation of your product spec when you do go to build.
Step 6: Decide with evidence, not enthusiasm
After two to four weeks of structured validation, you should be able to answer these questions with specific data rather than intuition:
- How many people confirmed they have the problem? (Aim for at least 10 matching your target profile.)
- How many expressed willingness to pay, and at what price?
- What do they currently use instead, and why is it insufficient?
- What is the one workflow they care most about?
If you cannot answer these with numbers, you have not finished validating.
Strong validation evidence also makes the development phase cheaper, because a well-defined problem produces a tighter spec, which produces fewer expensive surprises. When you are evaluating how to structure the development engagement, the pricing model you choose has real consequences. Fixed Price vs Hourly: Which Is Safer for Founders? walks through the tradeoffs in plain terms.
What validation does not guarantee
Validation reduces the risk of building the wrong product. It does not guarantee the business works. Distribution, pricing, competition, and timing all matter after the product exists. Validation answers a narrow question: do enough people want this enough to pay for it? The answer to that question is worth knowing before you spend anything on development.
It also does not mean validation must take months. Two focused weeks of interviews, a landing page test, and one manual pilot is enough to move from assumption to informed decision for most B2B software ideas. Consumer apps with broader audiences may need more data points, but the process is the same.
A note on ownership and IP during validation
If any part of your validation involves commissioning a prototype or proof of concept from a developer or AI-assisted service, confirm who owns the code before work begins. This matters even at the prototype stage. Who Owns the Code From an AI Dev Service? explains what to check and what contract language to look for.
FAQ
How long should software validation take?
Two to four weeks is enough for most B2B ideas if you run interviews and a landing page test in parallel. Consumer products with wider audiences benefit from longer testing periods, but the core question (will people pay for this?) can usually be answered in under a month with focused effort.
Do I need a working prototype to validate?
No. A landing page, a slide deck, or even a clear verbal description of the product is enough to test whether people want it. Save the prototype for validating the specific user experience, not the fundamental demand.
How many customer interviews are enough?
Ten to fifteen conversations with people who clearly match your target profile will surface the patterns that matter. More interviews add diminishing returns unless you are testing a second customer segment.
What counts as a strong signal of demand?
Someone paying money, even a small deposit, is the strongest signal. A signed letter of intent from a business customer is a close second. Email signups and survey responses are weak signals unless the conversion rate is unusually high and the audience was not pre-sold on the idea.
Should I validate before talking to any developers?
Yes, in most cases. Development conversations are more productive when you can describe the problem clearly, name the one workflow you want to automate, and explain who the user is. Validation gives you that clarity. It also protects you from scoping a product around technical convenience rather than actual customer need.