How to Validate a Software Idea Before Writing Code

We have built MVPs for dozens of founders. Some of those products are thriving businesses today. Others were shut down within six months. The difference almost never came down to code quality, design, or technical execution. It came down to whether the idea was validated before anyone started building.

Validation is not about predicting the future. It is about reducing the risk that you spend three to six months building something nobody wants. At Threshline, we actively encourage clients to do validation work before engaging us for development. It is better for them and better for us — building a product people actually need is more rewarding than building one that gets abandoned.

Here is the process we recommend, in order of effort required.

Step 1: Competitor Research (2-4 Hours)

Before anything else, find out what already exists. This is not about getting discouraged — competition is a good sign. It means the problem is real enough that people are paying to solve it. What you want to understand is: where are the gaps?

Search for direct competitors, adjacent tools, and forum threads where people complain about existing solutions. The best sources:

• Google — Search for your idea as a user would. “freelancer CRM”, “booking app for hair stylists”, “feedback tool for SaaS”
• Product Hunt — Search for keywords. Sort by newest to see recent launches
• G2/Capterra — Filter by rating and read the 2-3 star reviews. These reveal what users hate about existing solutions
• Reddit/Twitter — Search for people complaining about the problem you want to solve
• Indie Hackers — Search for people who have tried building similar things. Their post-mortems are invaluable

When we were researching the landscape before building Trackelio, our customer feedback platform, we found a crowded space — Canny, UserVoice, Nolt, Fider. But the 2-3 star reviews consistently complained about pricing for small teams and overly complex setups. That gap informed the product direction.

Document what you find: competitor names, pricing, what they do well, what users hate, and where your idea differs. If you cannot articulate a clear difference after this research, your idea needs refinement — not code.

Step 2: Talk to Potential Users (1-2 Weeks)

Competitor research tells you what exists. User interviews tell you whether people actually have the problem you think they have, how they currently solve it, and whether they would pay for a better solution.

You need 8-12 conversations. Not surveys — conversations. Surveys let people tell you what they think you want to hear. Conversations reveal how they actually behave.

How to Find People

• Post in relevant communities (subreddits, Slack groups, Discord servers, Facebook groups)
• Reach out to people who have reviewed competing products
• Ask your personal network for introductions
• Use LinkedIn to find people with the right job titles

What to Ask

The goal is to understand the problem, not pitch your solution. If you start describing your product, you have lost the interview. The person will nod along and tell you it sounds great because that is what humans do.

Instead:

• “Tell me about the last time you dealt with [problem].”
• “How do you handle [task] today?”
• “What is the most frustrating part of [workflow]?”
• “Have you tried any tools for this? What did you like and dislike?”
• “How much time/money do you spend on this currently?”

The magic question is about current behavior, not hypothetical future behavior. “Would you use an app that does X?” is worthless. “How much did you spend on solving this problem last month?” is gold.

What Good Signals Look Like

• People describe the problem without prompting, using emotional language
• They have tried multiple solutions and are still unsatisfied
• They can quantify the cost of the problem (time, money, missed opportunities)
• They ask you when your product will be available

What Bad Signals Look Like

• “Yeah, that could be useful” (lukewarm)
• They cannot recall the last time they had this problem
• They have a workaround that works fine (spreadsheet, existing tool, manual process)
• They are interested but only if it is free

After 8-12 conversations, you will see patterns. If 7 out of 10 people light up when describing the problem and can articulate their current workarounds, you have something. If most people shrug, go back to step one.

Step 3: Landing Page Smoke Test (1 Week)

A landing page test validates demand with actual behavior, not just words. You build a simple page that describes your product, its benefits, and its price. Then you drive traffic to it and measure how many people take an action — signing up for a waitlist, clicking a “buy” button, or entering their email.

What to Build

Keep it dead simple. One page. No backend. No authentication. A headline, three to four benefit statements, a rough price, and a call to action.

We use Astro for these — it builds to static HTML, deploys in seconds on Vercel or Cloudflare, and costs nothing to host. See our comparison of Astro vs Next.js for why we lean toward Astro for content-focused sites.

Headline: [Clear value proposition]
Subhead: [Who it's for and what they get]

Benefit 1: [Problem → Solution]
Benefit 2: [Problem → Solution]
Benefit 3: [Problem → Solution]

Pricing: Starting at $X/month

[Join the Waitlist] → Collects email

Where to Drive Traffic

You do not need a lot of traffic. 200-500 visitors is enough to get signal.

• Share in the communities where you found interview subjects
• Run a small ad campaign ($50-100 on Google or Meta) targeting the exact keywords your users would search
• Post on relevant forums with a genuine “building this, looking for early users” message
• Share on Twitter/LinkedIn if you have an audience

How to Evaluate

• Email signup rate above 5% — Good signal. People want to know when this exists.
• Email signup rate below 2% — Weak signal. The positioning or the idea needs work.
• People reply to your confirmation email with questions — Strong signal. They are engaged.
• Ad clicks are cheap but nobody signs up — The positioning is off. People click because the ad is interesting, but the page does not convince them.

A landing page test does not prove your product will succeed. It proves that real people, faced with a description of your product and its price, take the action of giving you their email. That is a meaningful data point.

Step 4: Willingness-to-Pay Test

The hardest validation signal to get is whether people will pay. Email signups are free commitments. Payments are real.

There are two approaches we have seen work:

Pre-Sale with a Refund Guarantee

Before building, offer a pre-sale. “Get lifetime access for $99 (regular price $199). Full refund if we don’t ship by [date].” This works best for prosumer and B2B tools where the buyer is comfortable with the concept of pre-orders.

The “Fake Door” Test

Add a “Buy Now” or “Start Free Trial” button to your landing page. When someone clicks it, show a message: “We’re not quite ready yet. Enter your email and we’ll notify you when we launch. As a thank-you, you’ll get 50% off.” Track how many people click the buy button versus how many just read the page.

This feels dishonest to some people. We think it is fine as long as you are transparent about the product not existing yet. You are not taking anyone’s money. You are measuring intent.

What the Numbers Mean

If you can get 10-20 people to pre-pay for a product that does not exist yet, you have strong validation. These are your first customers, your beta testers, and your most important feedback source.

If nobody pays, that does not necessarily mean the idea is bad. It might mean the price is wrong, the positioning is unclear, or the audience is not ready. But it is a signal worth taking seriously.

When to Stop Validating and Start Building

Validation can become its own form of procrastination. We have seen founders spend six months “validating” because they are afraid to commit. Here are the signals that validation is done and building should start:

• You have talked to 8+ potential users and the problem is consistent
• Your landing page converts above 3-5% on email signups
• At least a few people have asked when they can use it or offered to pay
• You can describe your ideal first user in one sentence
• You know your first three features and can explain why each one matters

If you have these signals, further validation has diminishing returns. The next best validation is an actual product in the hands of actual users.

When Validation Says No

Sometimes the data tells you the idea does not work. This is the hardest part, and it is the entire point of validation. If interviews are lukewarm, the landing page does not convert, and nobody offers to pay, you have saved yourself months of building the wrong thing.

That does not mean you give up. It means you pivot. Adjust the positioning, the target audience, or the core value proposition. Then run the validation loop again. Each iteration gets faster because you understand the market better.

When we built SpotsMexico, the initial concept was broader — a general location directory for creatives. Validation conversations revealed that photographers had the strongest pain point and the most willingness to pay. Narrowing the focus to photography locations made the product viable.

The MVP Comes After Validation

We covered how to prioritize features for an MVP in a previous post, but the critical point is: the MVP is not the validation step. Validation comes first. The MVP is what you build after you have evidence that people want what you are offering.

Too many founders confuse building an MVP with validating an idea. They are different activities. Validation answers “should we build this?” The MVP answers “what is the smallest version that delivers value?”

The founders who come to us after doing validation work — even informal, scrappy validation — build better products. They know who their user is. They know which features matter. They do not waste sprints on speculative functionality. And their products are more likely to find users after launch because they started with a real problem.

If you have validated an idea and are ready to build, reach out at [email protected].