How to validate an AI product idea before you build it
A practical way to test an AI product idea in weeks, not months: prove the problem, check AI is the right tool, prototype the hard part and test the price.
Most AI products don't fail because the model wasn't clever enough. They fail for ordinary reasons: not enough people had the problem badly enough, the problem didn't actually need AI, or nobody worked out who would pay for it until after it was built.
All three can be tested before you write production code. Here's the process I use in the idea phase.
Write the problem down without the word "AI"
Describe who has the problem, what it costs them today and what they do about it now, in one or two sentences, without mentioning AI. For example: "Small removals companies lose jobs because quoting takes a day; customers book whoever replies first."
If you can't write that sentence, you have a technology looking for a problem. That's fine for research, but it's an expensive way to start a product.
Talk to the people who have it
Find eight to ten people who fit the description and ask about the last time the problem happened. What did they do? How long did it take? Did they pay for anything to make it go away? Past behaviour is far more reliable than "would you use this?", which almost everyone answers politely with yes.
Listen for workarounds. A spreadsheet someone maintains by hand, a contractor they pay, a tool they bend to fit: workarounds are proof the problem is real and a clue to what a solution is worth.
Check that AI is the right tool
AI is a strong fit when the work involves messy language or documents, judgement across lots of examples, or drafting something a person then checks. It's a weak fit when the answer must be exactly right every time with no review, when simple rules would do, or when the data it needs doesn't exist.
Ask one question early: what happens when it's wrong? If a wrong answer is cheap and easy to spot, AI can act on its own. If it's costly, design for a person to review the output, and price that review in.
Prototype the hard part first
Don't start with the login screen. Take 20 to 50 real examples of the task, run them through an off-the-shelf model with a well-written prompt, and grade the results honestly against what a good human would produce.
That small set becomes your first evaluation set. It tells you whether the core idea works today, where it breaks, and roughly what each task will cost to run. If quality is poor at this stage, more engineering rarely saves it. Change the scope instead.
Put a price on it before you build
Show the people you interviewed what the product would do and what it would cost. A real price, not "it'll be affordable". Better still, ask for a commitment: a paid pilot, a deposit or a signed letter of intent. Interest is free; money tells you something.
Also check the economics from the other side. If each task costs a few cents to run and saves someone twenty minutes, there's room for a business. If the margins only work at a volume you can't reach, find out now.
Decide: go, change or stop
End the idea phase with a decision, not a deck. Go if the problem is real, AI handles the hard part well enough, and people will pay. Change the scope if one of those is shaky. Stop if two are. Stopping early is a good result: it's the cheapest version of the lesson.
At the end of this phase you should have a one-page concept, interview notes, a small evaluation set with results, a cost-per-task estimate and a clear go or no-go. That's what the idea phase produces with DevTrust, and it's the foundation for building the MVP.