The most expensive piece of software anyone can build is the one nobody ends up using. Not the buggy one, not the ugly one — the one that's technically fine but solves a problem nobody was actually willing to pay to have solved. It's expensive not just in development cost, but in the months of runway, attention, and momentum that go with it.
Validation exists to prevent exactly this outcome, and yet it's the step most founders are tempted to skip. There's a reason for that: talking to strangers about a rough idea feels slower and more uncertain than opening an editor and starting to build. Building feels like progress. Validation often feels like standing still. That feeling is misleading — validation is how you protect the budget you're about to spend, and it's almost always cheaper than the alternative of finding out you were wrong after the invoices start arriving.
What validation is actually for
Validation isn't a formality you perform to satisfy an investor deck or a checklist. It has one job: to reduce the number of expensive guesses in your plan before you turn them into code.
There are three kinds of guesses worth separating:
- Does the problem exist for enough people, at enough intensity, that they'd change behavior to solve it?
- Will people pay — with money, time, or a real commitment — for a solution, or is this a "nice to have" they'd never prioritize?
- Can we deliver this workflow in a way that's actually usable, or does the real version turn out to be far messier than the pitch made it sound?
Most founders instinctively validate the first one and skip the other two. All three matter, and the second one — willingness to pay or commit — is the one that kills the most ideas that otherwise "sound right."
Cheap validation before you hire engineers
None of the following require a single line of production code, and all of them produce evidence, not opinions.
- Talk to 10–20 target users about the job, not your feature list. Ask what they currently do to solve this problem, what they've tried, and what it costs them in time or money to live with it today. Resist describing your solution until near the end of the conversation.
- Test a landing page or waitlist with a clear, specific offer. Vague interest ("sounds cool") is not evidence. An email address, a deposit, or a scheduled call is.
- Run a concierge version manually. Do the workflow by hand for a handful of real users before automating any of it. This tells you what actually matters in the workflow, which is often not what you assumed when you sketched the feature list.
- Sell a pilot before you build every screen. If someone will commit budget or time to a pilot based on a clear description and a rough prototype, that's a far stronger signal than a survey response ever will be.
What "validated enough" actually looks like
There's no single threshold that applies to every idea, but a few signs consistently separate ideas worth funding from ideas worth reconsidering:
- People describe the pain in their own words, unprompted, before you've described your solution to them.
- At least one real person or company is willing to pay, pilot, or commit meaningful time — not just say something encouraging in a conversation.
- You can describe one primary workflow clearly enough that a small team could build a usable first version of it without you in the room explaining every edge case.
If the strongest evidence you have is that people were polite about your idea in a fifteen-minute call, you don't have validation yet — you have a pleasant conversation.
Signs you're rationalizing, not validating
It's worth being honest about a few patterns that feel like validation but usually aren't:
- Friends, family, and people who already like you telling you it's a great idea. They're not your buyer, and they know it, even if they don't say so.
- A large number of people saying they'd "definitely use it" with no follow-up action attached. Interest without commitment is nearly free to express and doesn't predict much.
- Comparing your idea favorably to a competitor without ever talking to that competitor's actual customers about what they'd switch for.
None of these are validation. They're the encouraging noise that happens around every idea, including the ones that fail.
When to actually start building
Once the job-to-be-done is genuinely clear, and you have real evidence of demand rather than encouragement, that's the point to fund something — but fund a small, shippable slice of the product, not the entire roadmap you've had in your head since the beginning. The first build should test the riskiest remaining assumption, not showcase every feature you're excited about.
A useful rule: if you can't say specifically what you'll learn from the first version that you don't already know, you're not ready to build it yet — you're ready to plan a bigger validation step instead.
ConaiSoft prefers working with founders who want evidence-based builds rather than roadmap-first ones. When the problem is validated, we help turn it into production software through short, visible sprints — so the first real spend goes toward something you already have reason to believe in.