Software
Discovery and
Scoping
Most software is priced before anyone knows what it is. We run a short, fixed-fee phase that settles what the system has to do, who it does it for and what it costs, then hand you a specification you can build from with us or without us.
45%
AVERAGE BUDGET OVERRUN ON LARGE IT PROJECTS
56%
LESS VALUE DELIVERED THAN PREDICTED
47%
OF FAILED PROJECTS BLAME REQUIREMENTS
What a two-page brief leaves out
Someone writes a page and a half describing the idea. Three developers quote against it and the numbers are miles apart, because each one has silently assumed a different system.
Then week six arrives and someone asks what happens when a customer cancels after paying a deposit. Refund, credit note or neither. Who gets told. Whether the booking still counts in the month's figures. That single answer changes the data model, and the data model was built in week two.
Most of the overspend goes on rewriting code that was correct for the wrong description of the business.
WHAT THE BRIEF SAYS
- "Customers can book online"
- "Admin can manage everything"
- "It syncs with our CRM"
- "Payments via Stripe"
- "A reporting dashboard"
- "Works on mobile"
WHAT A DEVELOPER HAS TO DECIDE
- Who can cancel, refund and who gets notified
- Which admin sees which client's records
- Which side wins when both change the same field
- What a partial, failed or disputed payment does
- Which numbers, from which source, refreshed when
- Which three screens people use on a phone
The five things that move the price
Estimates swing on a handful of decisions. We make them in week one, in front of the people who own the answer, and write down what was agreed.
The real workflow
How the job is done today, including the spreadsheet nobody mentions and the step that only one person knows how to do.
Data and its rules
What you store, what has to be unique, what can never be deleted, and which record wins when two systems disagree.
Who can do what
Roles, approvals and the records each one may see. Retrofitting permissions costs far more than designing them in.
The systems it touches
Which platforms, which direction the data flows, what the API actually allows, and what the software does while one of them is down.
What we are not building
Written down and signed off. The features held back for version two, and the reason each one was held back.
Two to three weeks, fixed fee
Discovery is quoted and invoiced on its own, separately from any build. You agree the fee before we start and it doesn't move.
At the end you can commission us, take the specification to another developer, or decide the project isn't worth doing. All three are fine outcomes, and the third is cheaper than finding out in month five.
BOOK A SCOPING CALLSit with the people doing the job
Not only the sponsor. The person who chases the missing paperwork, the one who reconciles the numbers on a Friday, the one who knows why the last system was abandoned. Usually four to six conversations.
Work through the messy cases
Half-payments, cancellations, duplicates, staff who leave mid-job, the client who wants an exception. We put the list in front of whoever owns the decision and get an answer while it's still cheap.
Prove the risky bit early
Where a project hangs on one uncertainty, we test it during discovery. Whether the API exposes the field you need, whether the model reads your documents accurately enough, whether the data is clean enough to import.
Write it down and price it
Screens, data rules, permissions, integrations, non-goals, and a build sequence with a fixed price per phase. Detailed enough that a developer who has never met you can quote from it.
What the research says about scoping
Overruns cluster around requirements. These are the studies most often cited, with their limits noted.
5,400 projects, 45% over budget.
McKinsey and the BT Centre for Major Programme Management at Oxford studied more than 5,400 IT projects. On average they ran 45% over budget and 7% over time while delivering 56% less value than predicted. The sample skews to large projects with budgets above $15m.
47% missed goals on requirements.
The Project Management Institute reported that 47% of unsuccessful projects missed their goals because of inaccurate requirements management, and 37% of organisations named inaccurate requirements as the primary cause of failure. Self-reported by project professionals.
17% threaten the company.
The same McKinsey and Oxford work found 17% of large IT projects go badly enough to threaten the existence of the company running them. Standish Group's separate CHAOS work has reported comparable failure rates for two decades, though its methodology is contested.
Sources: McKinsey & Company with the University of Oxford (2012), Project Management Institute Pulse of the Profession, Standish Group CHAOS.
Our client systems are shaped around existing work
AM2PM, Leo Associates, Crystal, Digbeth Events and Olton Bedrooms each got software built around how their own jobs already run, connected to the products they already relied on. That scope came from working through the detail with the people doing it.
When this is worth discussing
We work best when there is a real operating problem, enough volume to measure and people from the affected teams who can make decisions.
Usually a good fit
- An established UK business, usually with annual revenue above £10m
- A repeated process with a known cost, delay, error rate or capacity problem
- A senior sponsor and a day-to-day owner who understand the work
- Access to the relevant staff, systems, sample records and security requirements
We may point you elsewhere
- A standard product already covers the process well
- The requirement is a one-off small build with no wider operating case
- There is no owner or access to the people and data needed to test the result
- The plan relies on AI making high-impact decisions with nobody responsible for review
Questions before committing budget
Do we have to build it with you afterwards?
No. The specification is yours and it's written so another developer can quote from it. We'd rather be chosen on the build price than lock you in with a document only we can read.
How is this different from a free quote?
A free quote is a sales estimate written from your brief, which means the developer absorbs the unknowns by padding the number or by hoping. Discovery removes the unknowns first, so the build price is based on decisions you've already made rather than assumptions nobody wrote down.
What does discovery cost?
It's a fixed fee agreed before we start, sized to the number of workflows and systems in scope. For most projects it lands well under the cost of the first month of building, and where you go on to commission the build with us we credit it against the first phase.
We already have a specification. Do we still need this?
Send it over and we'll tell you honestly. Some are ready to quote from. Most describe the screens well and leave the data rules, permissions and failure cases open, which is where the estimate moves. If yours only needs the gaps closed, we scope that as a shorter piece of work.
What if discovery says don't build it?
Then we say so and explain why. Sometimes the answer is a configuration change in software you already pay for. Sometimes the process needs fixing before any system can help. We'd rather lose a build than take payment for something we don't think will work.
How much of our team's time does it take?
Roughly four to six hours per person across two weeks, spread over short sessions rather than workshops. We need the people who do the work, plus someone who can make a decision without going away to ask.
Can you scope a project that's already started?
Yes, and it's common. A build that has stalled usually has an unwritten decision at the bottom of it. We work out what has been agreed, what has been assumed and what still has to be settled, then reprice the remaining work honestly.
Tell us what you're trying to fix
Describe the process that's costing you time and who it involves. We'll tell you whether it needs a discovery phase, a smaller piece of work, or nothing from us at all.
Have an idea rather than a project? Start with what goes into a build-ready spec.