You've got a software idea. Maybe it's a product to sell. Maybe it's an internal tool to fix an operational headache. Either way, you're ready to build.
Stop.
Most software projects fail. Not because of bad code or missed deadlines—but because they solve problems that don't exist, or solve real problems in ways nobody wants.
Validation before development isn't optional. It's the difference between a successful project and an expensive lesson.
Why Validation Matters
Building software is expensive. Even a modest custom application costs tens of thousands of dollars. A complex platform can run into hundreds of thousands.
That investment makes sense when you're solving a real problem with a solution people actually want. It's catastrophic when you're not.
The companies that succeed with software share a pattern: they validated ruthlessly before building. They talked to users. They tested assumptions. They killed bad ideas early.
The companies that fail share a different pattern: they assumed they knew what was needed, skipped validation, and built something nobody wanted.
Which pattern do you want to follow?
The Validation Mindset
Validation isn't about confirming your idea is good. It's about finding out if it's wrong.
This is uncomfortable. You're emotionally invested. You've been thinking about this for months. You want it to be right.
But your job in validation is to kill the idea. Test every assumption. Look for reasons it won't work. Try to prove yourself wrong.
If you can't kill the idea despite genuine effort, it might actually be good.
Step 1: Define the Problem Clearly
Before validating a solution, validate the problem.
Write it down in one sentence:
- "Our warehouse team wastes 3 hours per day on manual order entry."
- "Customers can't see real-time inventory, so they call us 50 times per day."
- "Sales reps can't access customer history on the road, so they lose deals."
If you can't articulate the problem clearly, you're not ready to build. Go talk to more people until you can.
Questions to answer:
Is this problem real or perceived? You think it's a problem. But have you measured it? Observed it? Talked to the people experiencing it?
Sometimes problems are real. Sometimes they're management assumptions. Validation tells you which.
How painful is it? Not all problems deserve software solutions. A minor annoyance doesn't justify $100,000 in development.
Rate the pain:
- Critical: Business can't function properly without solving this
- Significant: Costs real money or time regularly
- Moderate: Annoying but manageable
- Minor: Would be nice to fix someday
Build software for critical and significant problems. For moderate and minor, look for simpler solutions first.
Who experiences it? The person requesting software and the person experiencing the problem aren't always the same.
A manager might request a reporting dashboard. But the real pain might be experienced by the analyst who spends hours compiling data manually. Talk to both.
How are they solving it today? If people aren't solving the problem at all, ask why. Maybe it's not painful enough. Maybe they've given up. Maybe there's a reason solutions don't work.
If they are solving it—with spreadsheets, workarounds, manual processes—that's validation the problem is real. Study those workarounds. They'll inform your solution.
Step 2: Validate the Solution Concept
Once you're confident the problem is real and worth solving, test solution concepts.
Note: concepts, not software. You're testing ideas, not building products.
The landing page test
For products you plan to sell:
Create a simple landing page describing what you plan to build. Include a call to action—email signup, waitlist, "request demo" button.
Drive some traffic. This doesn't require a huge budget. A few hundred dollars in targeted ads can tell you a lot.
If people sign up, there's interest. If nobody bites, either your messaging is wrong or the demand isn't there.
This test costs hundreds of dollars. Building the wrong product costs tens of thousands.
The mockup test
For internal tools:
Create mockups or wireframes of the proposed solution. These can be simple—PowerPoint slides, Figma mockups, even hand-drawn sketches.
Show them to actual users. Not their managers—the people who would use this daily.
Watch their reactions:
- Do their eyes light up?
- Do they immediately suggest improvements?
- Do they seem confused about why they'd need this?
- Do they point out things you hadn't considered?
Mockup tests reveal whether your solution concept resonates. They also generate better ideas—users often see possibilities you missed.
The concierge test
Before building automation, do it manually.
If you're planning software to match customers with products, do the matching manually first. If you're building an ordering portal, take orders via email or phone and process them by hand.
This is slower and doesn't scale. That's fine—you're not trying to scale yet. You're trying to learn.
Concierge testing reveals:
- What the actual workflow needs to be
- Edge cases you hadn't considered
- Whether the value proposition holds up
- What features are essential vs. nice-to-have
You learn more from one week of concierge testing than one month of planning.
The competitor test
Is anyone else solving this problem? If so, why wouldn't you use their solution?
Sometimes the answer is clear: "They don't integrate with our ERP" or "Their pricing model doesn't work for wholesale." These are valid reasons to build custom.
But sometimes the answer reveals you haven't done enough research. Existing solutions might work with some adaptation. The build vs buy decision deserves serious analysis.
If competitors exist and are thriving, that's validation the problem is real. If no competitors exist, ask why—maybe the market is too small, or the problem is harder than it looks.
Step 3: Validate the Business Case
A validated problem with a validated solution still needs a valid business case.
For revenue-generating products:
Who will pay? Not who might be interested—who will actually pay money?
Talk to potential customers. Ask what they currently spend on this problem. Ask what they'd pay for a solution. Get specific.
"I'd definitely buy that" means nothing. "I'd pay $500/month for that, and here's my card" means something.
What's the market size? How many potential customers exist? How much would they each pay? What's the realistic capture rate?
A $10 million market where you capture 5% is $500,000 in revenue. Is that enough to justify development costs?
What's the path to customers? Building software is one challenge. Getting customers is another.
How will you reach buyers? What will customer acquisition cost? How long will sales cycles be?
Many products fail not because they're bad but because the founders underestimated distribution challenges.
For internal tools:
What's the ROI? Calculate the actual return. Not "this will save time" but "this will save 3 hours per day across 5 people at $50/hour loaded cost = $750/day = $195,000/year."
Compare to development cost. A $100,000 build that saves $195,000/year pays back in six months. A $100,000 build that saves $20,000/year takes five years.
Simple MVPs can be built quickly, but even fast builds need to justify their cost.
What's the opportunity cost? That $100,000 could fund other initiatives. Those developer-hours could build other things.
Is this the highest-value project you could do right now? Validation isn't just "is this good"—it's "is this the best use of resources."
What happens if you don't build it? Some problems get worse over time. Some stay the same. Some resolve themselves.
If you do nothing, what happens in two years? This helps prioritise.
Step 4: Validate Feasibility
Some ideas are great in theory and impossible in practice.
Technical feasibility
Not "can software do this" but "can software do this within your constraints?"
- Does the necessary data exist and is it accessible?
- Are the required integrations possible?
- Are there technical risks or unknowns?
A fractional CTO can help evaluate technical feasibility before you commit to development.
Organisational feasibility
Will people actually use this?
The best software fails if:
- Users resist the change
- Training isn't provided
- Management doesn't enforce adoption
- The tool doesn't fit existing workflows
Talk to stakeholders. Understand the organisational dynamics. Identify potential resistance early.
Resource feasibility
Do you have what it takes?
- Budget for development and ongoing maintenance
- Time to manage the project properly
- Staff to support rollout and adoption
- Patience for the inevitable challenges
Underestimating resources is a common failure mode. Be realistic about what you can actually commit.
Red Flags During Validation
Watch for these warning signs:
"Everyone thinks it's a great idea." If nobody pushes back, you're probably only talking to people who'll agree with you. Seek out sceptics.
"We just need to build it and they'll see." If you can't get buy-in for the concept, you won't get adoption for the product.
"The market research says there's demand." Generic market research doesn't validate your specific idea. Talk to real potential users about your specific solution.
"Our competitor is doing it." Competitors might be wrong. Or their context might be different. Validate for your situation.
"It worked at my last company." Different company, different context, different constraints. Validate fresh.
"The boss wants it." Executive enthusiasm doesn't equal user adoption or business value. Validate anyway.
When to Stop Validating
Validation can become procrastination. At some point, you need to build.
You've validated enough when:
- The problem is clearly defined and confirmed real
- The solution concept resonates with actual users
- The business case is positive with realistic assumptions
- Technical and organisational feasibility are confirmed
- You've genuinely tried to kill the idea and couldn't
This doesn't mean certainty. You'll never be certain. But you should be confident you're solving a real problem with a viable approach.
The Cost of Skipping Validation
We've seen the same story repeatedly:
Company skips validation. Spends six months and $150,000 building software. Launches to users who don't want it. Spends another six months trying to fix it. Eventually abandons the project.
Total cost: $200,000+ and a year of effort. Plus the opportunity cost of what they could have built instead. And if they chose the cheapest quote, the number might be even higher.
Proper validation takes weeks, not months. It costs thousands, not hundreds of thousands. And it either confirms you're on the right track or saves you from an expensive mistake.
There's no scenario where skipping validation is the right choice.
Next Steps
Before your next software project:
- Write down the problem in one clear sentence
- Talk to users who experience the problem daily
- Test solution concepts with mockups or manual processes
- Build the business case with realistic numbers
- Assess feasibility across technical, organisational, and resource dimensions
- Write a proper brief to capture what you've learned and ensure your development partner understands what you need
Then, and only then, start building.
Have an idea you're not sure about? Book a call with our team. We'll help you validate it honestly—and tell you if we think it's worth building.
