Anyone Can Build Now. That's Exactly Why You Need a Validation Framework.
- Alex Baker
- Jul 8
- 4 min read
A couple of years ago I wrote that you don't need a working product to validate your idea. You don't need to raise a round, hire a dev team, or write a line of code to know whether what you're building is worth building. That was true then. In the age of vibecoding, it's become even more important.
The cost of building has fallen off a cliff. A founder with a good prompt and an afternoon can now stand up a working prototype that would have taken a team a quarter and a six-figure budget three years ago.
Law firms that would once have bought a tool from a vendor are now spinning up their own — a partner with an idea, a couple of AI tools, and some internal enthusiasm can have something clickable by Friday.
This is genuinely exciting.
When building is cheap, the temptation is to skip the thinking
For as long as software has existed, the constraint was construction. It was expensive and slow to build the wrong thing, so there was a natural, painful incentive to make sure you were building the right thing first. Validation was forced on you by the cost of getting it wrong.
With development costs collapsing, the forcing function. of validation has also diminished. When you can build the thing in a weekend, you build it. You skip the problem statement, skip the customer conversations, skip the market sizing, and go straight to a demo. You end up with a beautiful, working answer to a question nobody asked.
So the bottleneck to building a successful legal tech business hasn't been removed, it's just moved. It used to be can we build it? Now it's should we, for whom, and will they pay?
Those are the same questions I've always pushed founders to answer - but the collapse in build cost has made them more important, not less. The cheaper it is to build, the more solution noise there is in the market.
This is doubly true for firms building their own solutions
I advise on both sides of this: the legal-tech companies selling in, and the law firms productising their own expertise. The firms are the ones I'd urge most strongly to slow down before speeding up.
A law firm building its own tool has a real advantage — deep domain knowledge and a live client base to test against. But domain expertise is not the same thing as a validated product. Knowing the law is not knowing whether a defined buyer will change their behaviour, part with budget, and keep using the thing you've built. Those are separate problems, and the second one is where most internal builds being to struggle - a tool that works, that the team is proud of, that no one outside the building actually adopts.
"We understand the problem better than anyone" is the most seductive reason to skip validation, and the most costly. Understanding the problem in the abstract is not the same as evidencing it in a way that would convince a sceptical buyer — or a funder.
The framework: build the case before you build the product
So here's a simple framework if you are pre-MVP stage. It's a checklist of thirteen assets, grouped into five stages, and none of them require a line of production code:
Foundation — the problem statement and hypothesis, a real base of customer-discovery conversations, and a tightly-defined ideal customer. This is the actual work. Get agreement that the problem is real and quantified, and you've proven your solution has value before you've built it.
Market — how big the obtainable opportunity is, sized bottom-up, and an honest map of what people use to solve this today (including "nothing"). "No competition" almost always means "no market".
Solution — a sharp value proposition, and a definition of the thinnest thing that tests your hypothesis. This is where you finally decide what the product is — after the evidence, not before it.
Commercial — your sales process and qualifying questions, your pricing logic, and any early evidence of pull: letters of intent, pilots, a waitlist. Willingness to pay is part of validating the problem. Real pain gets paid to remove.
Funding — the business and financial plan, the team narrative, and only then the pitch deck. The deck is a synthesis of everything above, not a substitute for it. Build it last.
The order matters. The first three are the real work; the funding pack (or resource requirements if you're self funding) is the packaging. Most of these assets are cheap to produce and they compound — each one feeds the next.
Why use it
If you're building to create a business, the thing that used to protect you from building the wrong product - the sheer cost and effort of building — is gone. The discipline that was once imposed by circumstance now has to be chosen deliberately.
A framework like this is how you choose it. It's a cheap insurance policy against an expensive mistake, and it doubles as the evidence base you'll need the moment you want to raise money, get internal sign-off, or take a product to market.
When you walk into a funding conversation, "here is one validated problem, a quantified market, and early traction" beats "here is a working demo and four more ideas" every time.
Everyone now has the ability to build. That's precisely why the advantage now goes to the people who know what to build, for whom, and why. The demo was never the hard part. It's just the last thing you should do — not the first.
I put the full thirteen-asset checklist on a single page. If you're at the pre-MVP stage, whether you're a founder or a firm building your own, use it as a gut-check before you write another line of code.
Comments