Most software projects that fail do not fail because of poor development. They fail because someone built the wrong thing. The code worked. The product launched. And then almost nobody used it, or the people who did use it wanted something entirely different from what was built.
This is an expensive way to learn. A custom software project can run anywhere from tens of thousands to hundreds of thousands of dollars. Spending that money to find out your assumptions were wrong is a risk you can mostly avoid — if you validate the idea before you commit.
This post covers what validation actually means, how to do it without building anything, and when it is appropriate to stop validating and start building.
What Does "Validating a Software Idea" Actually Mean?
Validation means testing your core assumptions about who wants your software and why, using the cheapest evidence you can get before you invest in building it.
Most software ideas rest on a chain of assumptions. That a specific group of people has a specific problem. That they currently solve it in a way that is painful or inadequate. That they would switch to something better. That your proposed solution is actually better. That they would pay for it, or use it enough to justify the investment.
Every link in that chain is a hypothesis. Validation is the process of testing those hypotheses — ideally in order of importance, and ideally before you spend money on development.
The opposite of validation is not confidence. It is assumption. And the more expertise you have in a domain, the easier it is to believe that your read on the problem is correct without checking it against the people you are building for.
Why Validation Fails (or Gets Skipped)
There are two reasons most software ideas skip proper validation.
The first is urgency. "We need to move fast" is used to justify skipping the very step that would tell you whether you are moving fast in the right direction. Speed matters. But speed toward a wall is not an advantage.
The second is false confidence. Talking to a few colleagues who agree the idea sounds good is not validation. Getting enthusiastic responses to a concept deck is not validation. A vendor telling you the solution is buildable is definitely not validation. These feel like signal, but they are mostly noise — people who like you, people who have not thought hard about whether they would actually use the thing, or people with a financial interest in you saying yes.
Real validation involves friction. Someone commits time, money, or effort based on the thing you are proposing to build. That commitment — however small — is evidence. Enthusiasm without commitment is not.
How to Validate Before You Build
The following steps are roughly in order of cost and fidelity. You do not need all of them — the right approach depends on what you are building and how confident you already are in your assumptions.
1. Document your assumptions explicitly
Before you can test assumptions, you have to write them down. Most people skip this step because it seems obvious. It is not.
Write out: Who is this for? What problem are they experiencing today? How do they currently handle it? Why is that insufficient? What would they switch to instead, and why? What would make them do nothing?
This exercise usually reveals at least one assumption you have never explicitly tested. Start there.
2. Talk to potential users — properly
Not a pitch. A structured interview. The goal is to understand how they actually handle the problem today, not to assess their interest in your solution.
Ask about current behaviour, not hypothetical behaviour. "How do you handle X right now?" tells you something real. "Would you use a tool that did X?" tells you almost nothing — people are unreliable predictors of their own future behaviour.
Ten to fifteen in-depth conversations with people who fit your target user profile will surface patterns you could not have anticipated. They will also reveal whether the problem you are solving is a genuine source of friction or something people have learned to live with without noticing.
3. Test demand with a landing page
A landing page describes the problem you are solving and what your solution would do, and includes a call to action — an email sign-up, a waitlist, an "I'm interested" form. Then you send traffic to it and measure what happens.
This is one of the cheapest and most informative validation exercises available. If you can articulate the value proposition clearly enough to put it on a page, you will find out quickly whether the people you are targeting respond to it. Low conversion is information. High conversion is evidence.
Minimum viable product thinking, popularised by the lean startup movement, is rooted in this principle: test the smallest possible version of your idea before committing to the full build.
4. Manual before automated
Before you build software to do something, do it manually and charge for it.
If you are building a tool to automate a business workflow, run that workflow manually for a handful of paying customers first. If the manual version works and customers value it, you have evidence that the underlying idea is sound — and you understand the process well enough to build it properly.
This approach is underused because it feels like a step backward. It is not. It is the cheapest version of proof of concept testing available, and it keeps you close to the real problem rather than the abstraction of it.
5. Build a prototype — not a product
If you need to demonstrate the experience rather than just the idea, build the lightest possible version of the core flow. Not a complete product. Not a polished UI. The one screen or interaction that tests whether the fundamental experience works.
A prototype built in a few days with a tool like Figma, or with a no-code builder, tells you more about user comprehension and workflow fit than months of full development would. It is also disposable, which matters — being willing to throw away a prototype is far easier than being willing to throw away a system that took six months to build.
What You Are Looking for
Across all of these methods, you are looking for the same thing: do real people, facing the problem you are targeting, want this enough to do something about it?
The signals that matter:
- People change their behaviour based on what you show them
- People pay money, or would pay money, for the solution you are describing
- People refer you to others before you have asked them to
- People tell you about the problem in terms you did not anticipate — which means they have lived with it enough to develop their own vocabulary for it
The signals that do not matter:
- People say the idea sounds great
- People say they "would definitely use it"
- Colleagues in your industry say there is a gap in the market
Enthusiasm without commitment is not evidence. Behaviour is evidence.
When Is Enough Enough?
Validation does not eliminate risk. It reduces it. At some point, the cost of further validation exceeds the cost of just building — especially when you are solving your own problem, you have direct access to the user group, or the market is moving fast enough that extended validation creates its own risk.
The questions to ask before moving to development:
Can you describe the first ten people who will use this, and explain why they will? If the answer is vague, validate more. If you can name them, you are probably ready to build.
Do you know what the one thing is that has to work? Every good piece of software has a core. If that core does not work, nothing else matters. Knowing what it is tells you what to build first.
Have you talked to anyone who said no? If everyone you have spoken to is enthusiastic, you are probably only speaking to people likely to agree with you. Seek out people who would not use your product and understand why. Their objections are your greatest source of insight.
The Cost of Not Validating
Building the wrong thing is the most expensive outcome in software development — more expensive than a slow build, a difficult vendor relationship, or a scope increase midway through. A project that costs two hundred thousand dollars to build and serves a problem nobody has gets you nothing for that investment.
Validation typically costs a fraction of development time and money, and it gives you something far more valuable than a working system: confidence that the working system you are about to build is the right one.
If you are weighing a software investment and are not sure whether the idea has been tested enough, or if you want help structuring a validation process before engaging a developer, this is exactly the kind of work I do in technical advisory engagements. It usually takes a short conversation to identify what assumptions still need testing and what the lowest-cost path to testing them looks like.
You can also read about how I approach custom software projects more broadly, or get in touch if you want to talk through a specific idea.