There is a pattern we see very regularly when it comes to software projects.
A business owner or a director arrives with a brief. They know what they want. They have thought about it, talked about it internally, maybe even sketched it out. The brief describes a solution in detail: what it should do, what it should look like, roughly how it should work.
The brief is wrong.
Not because they are not smart. Not because they have not thought it through. But because the process of building a brief almost always starts from the wrong place.
The problem with solution-first thinking
When something is not working in a business, the instinct is to fix it. That is a good instinct. The problem is that the fix people reach for is usually the first thing that comes to mind, which is rarely the most important thing.
A team is spending hours each week manually copying data between two systems. The brief says: we need an integration.
A sales process is slow and inconsistent. The brief says: we need a CRM.
Customers are not getting quick enough responses. The brief says: we need a chatbot.
Each of those solutions might be right. But they might also be solving a symptom rather than the cause. And building the wrong thing well is far more expensive than taking three weeks to understand the problem properly first.
What happens when you build the wrong thing
The cost of building something is obvious. The cost of building the wrong thing is less visible but far higher.
You spend the budget. You spend the time. You go through the disruption of implementation. And then six months later you are looking at a piece of technology that does exactly what you asked for and not quite what you needed.
IBM research suggests that fixing a problem found in production costs up to 100 times more than catching it before development starts. Most businesses we speak to who have been burned by a software project were not let down by poor execution. They were let down by poor problem definition at the start.
Why briefs start in the wrong place
Most briefs are written by people who know their business well but have less experience of how technology actually gets built and what it can and cannot do.
That is not a criticism. It is just a reality. When you spend most of your time running a business, you think in terms of the problem you can see and the solution that seems obvious. You are not thinking about what the solution assumes, what it depends on, or whether there is a fundamentally different approach that would achieve the same outcome for half the cost.
There is also an element of wanting to feel prepared. Arriving at a meeting with a vague problem feels uncomfortable. Arriving with a fully formed brief feels more professional. So people translate their vague problem into a specific solution before they have spoken to anyone who knows whether that solution makes sense.
A real example
We were approached by a business that provides maintenance services to expensive machinery. They had a busy support desk handling hundreds of incoming requests every week. Their brief was straightforward: they wanted a chatbot to handle customer queries.
On the surface, that sounds reasonable. They had a volume problem and a chatbot seemed like an obvious fix.
But before we wrote a line of code we spent time understanding how their operation actually worked. We mapped the full journey of an incoming service request. We understood how their field management software was being used, what data existed where, what the team was actually doing each day.
What we found was not a chatbot problem. It was an intake and triage problem. Customers were contacting the business through multiple channels, the team was manually researching each request before they could respond, and there was no systematic way of prioritising based on the customer's service agreement level.
The right solution was an AI agent that sat across their inbound channels, automatically looked up customer and machine data, identified the correct service tier, and routed each request accordingly. A chatbot would have handled the surface conversation but left the underlying problem completely untouched.
The brief was wrong. The problem was solvable. The solution looked nothing like what had been asked for.
What good discovery actually looks like
Discovery is not a phase you pay for to keep an agency busy before the real work starts. It is the part of the project where you find out whether you are building the right thing.
Good discovery starts not with the solution but with the process. What actually happens today, step by step? Where does time get lost? Where do errors creep in? Where do people work around the system rather than through it?
It asks uncomfortable questions. Not just what do you want the system to do, but what would you do if you could not build anything at all? What is the underlying outcome you are trying to achieve?
It challenges the assumptions baked into the brief. Why does this need to be an app? Why does it need to do all of these things? Could you solve 80% of the problem with 20% of the build?
And it is honest about what it finds. Sometimes the answer is not a technology project at all. Sometimes the problem turns out to be a process problem that a technology investment would not solve. A good discovery process will tell you that before you commit the budget.
The cost of skipping discovery
We sometimes hear from businesses who have had a bad experience with a previous agency. The project ran over time. The budget ballooned. The end product did not do what was needed. The relationship broke down.
Almost every time, the root cause is the same. Insufficient time was spent at the start understanding the real problem. Everyone moved too quickly to the build. Assumptions were made and not tested. And by the time those assumptions turned out to be wrong, it was expensive to go back.
Discovery is not a luxury for larger projects. It is proportionally more important on smaller ones. A business spending £30,000 on a software project cannot afford to spend £25,000 of it building something that misses the point. The margin for error is smaller, not larger.
What we tell clients before we start
We always tell prospective clients the same thing. We are not in the business of building what you ask for. We are in the business of building what you need.
Those two things are often the same. But we always treat every brief as a starting point for a conversation rather than a specification to be executed.
We will challenge your brief. We will ask why. We will push back on assumptions. We might tell you that the problem you have described is real but the solution you have proposed is not the most effective way to address it. We might tell you that you should start with a smaller, more focused piece of work before committing to a larger build.
We might even tell you not to build anything at all, at least not yet.
That is not us being difficult. That is us doing our job properly. Because the most expensive mistake in software development is not building the wrong feature. It is building the wrong product.
How to get to the right brief
If you are about to start a software project, or thinking about one, there are a few questions worth sitting with before you write a brief.
What problem are we actually trying to solve? Not the technology problem. The business problem. What is costing you time, money, or customers right now?
How do we know this is the right solution? What assumptions does the brief contain? What would need to be true for the proposed solution to work?
What does success look like in concrete terms? Not features delivered. Business outcomes achieved. How will you know in six months that the investment was worth it?
What is the smallest thing we could build that would prove the concept? Is there a faster, cheaper way to test whether the approach is sound before committing to a full build?
Who else has solved this problem? Are there existing tools, platforms, or integrations that could solve the problem without a bespoke build?
You do not need to answer all of these before speaking to a development partner. But if you cannot answer the first one clearly, it is probably worth pausing before you write the brief.
The businesses that get the most value from technology investment are not the ones with the biggest budgets. They are the ones that take the time to understand what they are actually trying to achieve before they start building.
The brief is just the beginning of that conversation. Not the end of it.
Tappable is a bespoke software consultancy based in Bedford. We work with mid-market businesses on the technology and AI challenges that are limiting their growth. If you have a brief you would like to talk through, we are happy to start with the questions before we get to the answers.