Would you approve a software project before the idea has been tested? Most businesses do.

Would you approve a software project before the idea has been tested?
Most businesses do.

Most software investment decisions are made on the strength of a slide deck, a specification and a confident presentation. Nobody in the room has used the thing they're about to fund.

Then the build starts. And the real questions surface one expensive sprint at a time.

It's a strange way to commit six or seven figures. You wouldn't appoint a senior leader from a CV without ever meeting them. Yet software gets approved on descriptions every day.

The biggest risk in a software project isn't building it badly. It's building the wrong thing well. The cheapest point to find that out is before development starts. Here's how to test a software idea before building it, and what to ask before you sign.

Approval Is Not Evidence

A sign-off means the room agreed. It doesn't mean the room agreed on the same thing.

Take a line from a typical specification: "a dashboard that gives managers visibility of team performance." The CFO pictures three numbers on one screen. The operations lead pictures drill-downs by shift. The CTO pictures integrations with four systems nobody has mentioned yet.

None of those differences show up in the meeting. The words are the same, so everyone nods. The gaps only appear once designers and developers start making the thousands of small decisions a document never has to make. By then, the money is committed and the clock is running.

McKinsey's research includes a painful example. One bank's finance department only got involved a few months before a new system was due to go live. The changes it needed delayed the launch by more than three months, at a cost of more than $8 million. Nobody built the wrong thing on purpose. They just found out too late what "right" meant.

The Cost of Learning Late

That bank isn't an outlier. McKinsey and the University of Oxford studied more than 5,400 IT projects and found that large IT projects run, on average, 45% over budget and 7% over time, while delivering 56% less value than predicted.

The research dates from 2012 and focuses on projects with budgets above $15 million, so treat it as a long-standing pattern rather than a current benchmark. But the pattern is the point. Anyone who has worked in delivery will recognise it.

Look at those three numbers again. The overspend gets the headlines. The delay gets the board's attention. The one that should worry a CFO most is the third.

A 45% overspend on something valuable hurts. A project that lands on budget and delivers half the expected value is arguably worse, because it looks like a success on every report until someone asks what the business actually got for its money.

Much of that value gap isn't bad engineering. It's things that were built well and were never going to deliver. Assumptions nobody tested. Workflows that made perfect sense in a workshop and none at all on a Tuesday afternoon with a real queue of customers.

The same research found that every additional year a project runs increases cost overruns by 15%. Learning late doesn't just cost more. It compounds.

What People Say Versus What They Do

If you want to see where the value goes, look at what happens after launch.

Pendo's 2019 Feature Adoption Report analysed usage across 615 software products and found that 80% of features in the average product are rarely or never used. Around 12% of features generated 80% of daily usage.

It's worth knowing this comes from a software vendor's own customer data rather than independent academic research. Even so, it matches what most product teams see in their own analytics.

Here's the uncomfortable part. Very few of those features were built on a whim. Someone asked for them. Someone approved them. Someone paid for them.

That's the gap between opinion and behaviour. Workshops, interviews and requirements documents capture what people think they'll want. They're useful, but they're opinions. Put something tangible in front of the same people, let them work through a real journey with realistic data, and you capture behaviour instead. What they ignore. Where they hesitate. The question they ask that nobody thought to write down.

Behaviour is evidence. Opinion is a hypothesis.

What "Evidence" Actually Looks Like

So what should you ask for before approving a build? Not a longer business case. A sharper one.

These are the questions we'd take into any investment meeting. They work whether you're the one signing off or the one making the case.

• Which assumptions must be true for this to succeed? Every proposal rests on a handful. Users will give up the spreadsheet. The data exists and is clean enough. Teams will adopt a new workflow. Write them down and rank them by how much damage it would do if each one turned out to be wrong.
• Which of those have we actually tested? Not discussed. Tested. If the answer is "none of the important ones", that's your risk, sitting in plain sight.
• Who needs to experience it before we commit? Not approve it. Experience it. The end users, obviously. But also the finance team who will reconcile its output, the operations lead who will support it, and anyone whose buy-in the project depends on.
• What would make us change course? Agree it now, while nobody has a sunk cost to defend. Low adoption in testing, a journey users can't complete, a technical constraint that doubles the cost.
• What would make us stop? The same question, asked harder. If nobody in the room can name a result that would end the project, the decision has already been made and the evidence is decoration.
• What's the smallest thing we could build to find out? It's almost always far smaller than the first version in the specification.

If the person asking for budget can answer those clearly, you're funding a well-understood bet. If they can't, you've just found the cheapest point in the whole project to fix that.

Why Teams Skipped This Step

None of this is new thinking. Prototyping before a major build has been good practice for decades. The problem was the effort.

A realistic, interactive prototype could take weeks of design and front-end work. By the time it was ready, the pressure to just start building had usually won. So teams skipped it, and learned in production instead.

AI-assisted design and development has changed that. Experienced teams can now turn a concept into something people can genuinely use in days rather than weeks. It isn't production software, and it shouldn't pretend to be. But it's real enough to test the assumptions that matter, which makes a working software prototype before investment a realistic step rather than a luxury.

That shifts the maths. When testing an idea cost a month, skipping it was a defensible gamble. When it costs days, skipping it is just a gamble.

Stopping Is a Result, Not a Failure

Here's the reframe we'd encourage every leadership team to make. A test that tells you not to build something hasn't failed. It's done its job.

McKinsey describes a healthcare provider that was about to spend around $1 billion over eight years replacing a core system. Leadership stopped it at the green-light stage and sent it back for replanning. The revised plan came in line with comparable projects and still delivered the scope they needed. That decision never appeared as a shiny launch. It appeared as a disaster that didn't happen.

Most "no" results are less dramatic. A proposition users don't value. A workflow that falls apart with real data. The logic is the same either way. Every pound not spent on the wrong thing is a pound available for the right one.

The real obstacle is cultural. Nobody gets promoted for the project they stopped. If stopping feels like failure, teams will quietly avoid finding out. So make it explicit: a clear "no" is a result, and whoever delivered it just saved the business money.

Proceed, Change or Stop

Every properly tested idea ends in one of three places.

Proceed. The evidence supports the opportunity. You invest with confidence and a sharper scope.

Change. The opportunity is real, but something needs to shift before you commit further.

Stop. The evidence doesn't justify the spend, and you found out for a fraction of the cost of building it.

All three are good outcomes. The only bad one is committing a full budget without knowing which of the three you're in.

If you've got an idea on the table and a decision coming up, our AI prototyping team can help you get that evidence quickly, before the big money is committed. And if you're earlier than that, still shaping what the product should be, our UX & UI design and design sprint facilitation teams are a good place to start.