Most failed custom software projects did not fail in the build phase. They failed in the scoping phase, before a line of code was written.
UK SMBs commission custom software a few times in the lifetime of the business. Software agencies and consultancies do it every week. The asymmetry is structural: the seller knows exactly which scoping decisions hurt the buyer most, and the buyer often does not learn until two months in when the costs start escalating.
This post is the version of the conversation the bureau wishes more clients had before they commissioned anywhere. Eight specific scoping mistakes, what each one looks like, and how to avoid it.
Mistake 1: scoping the solution instead of the problem
The most common mistake. The conversation goes: "We need a CRM with these eight features. Can you build it?" The buyer has skipped from "we have a problem" straight to "build me this specific solution".
The trap: the eight features the buyer has in mind are usually the wrong eight features. They are derived from a half-remembered SaaS the buyer used years ago, plus three things a colleague suggested at a meeting. Building exactly that produces software the buyer does not actually want.
The fix: scope the problem first. What is actually breaking? Which workflows are bleeding time? What does the team do today that the new software needs to support? The features fall out of those answers, not the other way around.
The bureau's audit forces this order. The audit produces a problem statement before any solution gets discussed.
Mistake 2: not writing it down
The second most common. The buyer and the developer have a series of conversations, agree on a price, and start work. Nothing is written down. Six weeks in, the buyer says "I assumed it would also do X" and the developer says "you never told me about X". Both are right.
The fix: insist on a written specification before any code is written. Plain English, no jargon, agreed by both sides. If the developer cannot or will not produce one, the project is structurally going to fail. The bureau writes the specification as the deliverable of the audit; the build that follows is built against the specification.
A specification does not have to be long. A 5-page document covering "what the software does, who uses it, what data it stores, what it integrates with, what counts as done" is more than most failed projects ever had.
Mistake 3: scoping for "the way we wish we worked" instead of how we actually work
Buyers often describe an idealised version of their operations to the developer. The version where everyone follows the process, the data is clean, and the workflow is logical. The developer builds software for that idealised version.
The actual operations are messier. The salespeople use shortcuts the operations team does not know about. The accounts team has a workaround for invoices that do not fit the standard format. The customer service rep keeps a personal spreadsheet because the system does not handle one specific case.
When the software ships, the team cannot use it because it does not match how they actually work.
The fix: scope from observation, not from description. The bureau's audit watches the actual workflow run, not the version someone describes in a meeting. If you are commissioning anywhere else, insist on at least one structured observation session before the spec gets written.
Mistake 4: ignoring the integrations
A new piece of custom software almost never lives alone. It has to talk to the CRM, the accounts system, the email platform, the file storage, possibly the website. The integrations are usually 30 to 60% of the total work, and they are usually under-scoped.
A buyer asks for "a customer portal". The developer scopes the portal. Six weeks in, both realise the portal needs to read customer data from the CRM, generate invoices that go into Xero, accept document uploads that get stored in Google Drive, and send notifications via the company's existing email platform. Each of those is a non-trivial integration. None of them were in the original quote.
The fix: every scoping conversation should include a "what does this connect to?" inventory. List every system the new software has to read from or write to. Each one is its own scoping question. The bureau costs each integration separately so the trade-offs are visible upfront.
Mistake 5: skipping the data migration
If the new software replaces an old system, the existing data has to move. This is almost always harder than expected. The data is dirtier than expected. The fields do not map cleanly. There are duplicates. There are records that span both old and new states during the migration window.
A buyer who scopes "we want to replace X with this new system" but does not scope the migration ends up paying for it as scope creep, and discovering that the migration is a quarter of the total work.
The fix: scope migration as a separate workstream. Decide what data moves, what gets archived, what gets cleaned up first, and how the cutover happens. The bureau quotes migration as a line item, not as part of the build cost.
Mistake 6: not deciding what counts as "done"
The most expensive ambiguity in any scoping conversation. "Done" means different things to different people:
- The developer thinks "done" means the software passes its tests and runs in production.
- The buyer thinks "done" means the team is using it and the old system is decommissioned.
- The team thinks "done" means it is faster and easier than the old system, which it usually is not on day one.
Without a written definition of done, the project never finishes. Each side keeps adding requirements; the bill keeps growing; the relationship sours.
The fix: define done in writing, in the specification, before any code is written. Specific acceptance criteria. Specific test scenarios. A clear handover moment. The bureau writes this into every fixed-fee proposal.
Mistake 7: assuming the team will adopt it
Software that gets built but does not get used is the most expensive failure mode in custom software. The build cost is paid; the value is zero.
Adoption usually fails because the team was not involved in the scoping. Software dropped on a team without their input gets resented and worked around. The team continues to use the old way, the new system fills with stale data, and eventually somebody decommissions it.
The fix: include the people who will actually use the software in the scoping conversation. Not just the manager who is buying it. The salespeople who will live in the CRM. The operations admin who runs the reports. Their questions reveal the real workflow constraints.
The bureau's audit always includes time with the team using the software, not just the person commissioning it.
Mistake 8: not asking what happens if it goes wrong
Every project has a chance of going wrong. Scope changes, missed estimates, integrations harder than expected, key staff leaving mid-project. A good scoping conversation includes the question: "what happens if this does not go to plan?"
The bureau's answer is structural: every engagement is fixed-fee, fixed-timeline, fixed-scope. If the work takes longer than the quote, that is the bureau's cost, not yours. The contract has a clean termination clause. The code is yours on delivery, in a repository you control, with documentation, so you can pick up the work elsewhere if needed.
If the developer you are talking to cannot give a clean answer to "what happens if this overruns?", the answer is "you pay for the overrun" by default. Get it written down before you sign.
What a properly-scoped engagement looks like
A custom software build that has been scoped well has these properties:
- A written specification both sides agree on, in plain English.
- A fixed price, agreed before code is written.
- A fixed timeline, with milestones the buyer can verify against.
- A clear list of integrations, each costed separately.
- A scoped migration plan if there is data to move.
- Acceptance criteria that define "done".
- Inclusion of the actual users of the software in scoping conversations.
- A termination and ownership clause that protects the buyer.
If any of these are missing from a proposal you are evaluating, that is the scoping mistake the project is going to fall through later. Get them added before signing.
What Orchestrix does
Every custom software build the bureau quotes goes through a structured scoping process. The free 15-minute triage is the entry point: a conversation about what is broken and what the build needs to fix.
If the conversation suggests a build is the right answer, the next step is the operational audit (£2,500). The audit produces the written specification, the integration inventory, the migration plan, the acceptance criteria, and the fixed-fee proposal for each part of the work.
The audit fee credits in full against any build that follows. So if you proceed, the audit is free in net terms; if you do not, you walk away with a specification good enough to commission anywhere else.
A note on what the bureau does not do: build without an audit. Every "can you just quote on this scope I have written?" gets the same answer: scope quality is what determines whether the build succeeds. The audit is the bureau's way of making sure the scope is good before any code is written. If that order is not what you want, the bureau is the wrong fit for the project.