A client came to us last year with a clear brief. They wanted to build a platform. They had a number in mind, a rough set of features, and a timeline they'd already communicated internally.
Two weeks into discovery, we told them not to build it.
The problem they were trying to solve could be validated faster, cheaper, and with far more certainty using a manual process first. Once they had real data, real users, real evidence, the build would be sharper and significantly more likely to succeed.
They took the advice. Validated in eight weeks. Then we built it properly.
That story makes some people uncomfortable. Why would a software company talk a client out of spending money?
The honest answer: because it's the right thing to do. And because clients who trust us to give them that kind of advice are the ones who come back.
The brief is rarely the whole story
Most businesses that come to us have done a lot of thinking before they pick up the phone. They've identified a problem, sketched a solution, and in many cases already sold the idea internally. By the time they speak to us, they're looking for someone to execute the plan.
We question it anyway.
Not to be difficult. But because in fifteen years of working with businesses on software problems, the brief a client arrives with is almost never the same as the brief they leave with. The gap between those two things is usually where the real value is.
Some clients just want a yes man. And that’s ok. But that’s not how great partnerships are built.
The platform this client wanted to build was solving a symptom rather than a cause. The underlying problem was smaller, more specific, and far more addressable than the sprawling solution they'd designed around it. The build would have worked. But it would have cost more than it needed to, taken longer than it should, and delivered less certainty than a proper validation process could provide.
Telling them that wasn't comfortable. It meant pushing back on a decision that already had momentum. But it was the right call, and they knew it.
What discovery is actually for
There is a version of discovery that most software studios offer. It involves workshops, wireframes, and a document that sets out what will be built. It confirms the brief. It is a precursor to the build.
Discovery done properly is where the most important thinking happens. Where does the real cost sit in this business? What does success look like for the business, not just the product? What is the smallest version that proves the case?
Sometimes the answers confirm the brief. The client is right, the plan is sound, and we build it. But sometimes the questions reveal a better answer. A different scope. A phased approach. An intervention that costs a fraction of the original budget and solves the same problem.
In those moments, the most valuable thing we can do is say so.
The most expensive mistake in software
A well-executed solution to the wrong problem. A platform that does exactly what it was asked to do, built to spec, delivered on time and on budget, that nobody actually uses. Because the problem it solved was not the real problem. Because the brief was wrong from the start and nobody pushed back hard enough to find that out.
The honest conversation upfront is the most valuable thing a software partner can give you. It is also the rarest.
Why most studios skip it
Because it is commercially uncomfortable.
A client arrives with a budget and a brief. Saying yes keeps the conversation moving and puts revenue on the board. Saying "we think there is a better answer" risks losing the project entirely.
We would rather lose the project.
The clients we want to work with are the ones who value that honesty. Who want a partner that will challenge their thinking rather than just execute their instructions. Those clients come back. They refer others. They build relationships that go deeper than a single project.
The client we talked out of the £100k build came back six months later with a better brief, a clearer problem, and a project we were both proud of.
What this means in practice
Most clients who go through discovery with us do commission the software. But they commission it with a confidence they did not have at the start, because the brief has been tested, the scope shaped, and the budget is honest.
Instead of building on instinct and hope, they are building on evidence. Instead of a sprawling V1 that tries to do everything, they have a focused first version that proves the case before anyone commits to the rest.
Not every client is ready for that conversation. There are plenty of studios who will take a brief as given and start building. For clients who want that, we are probably not the right fit.
For the ones who want someone to help them make the right decision rather than just a fast one, that is exactly what we are here for.
If you are considering a software investment and want someone who will tell you what you need to hear, we would be glad to have that conversation.
Tappable is a bespoke software consultancy based in Bedford. We work with mid-market businesses and scaling organisations on the technology problems that are limiting their growth. We figure out what the right solution is, then we build it.