Choosing a Software Consultancy in the UK: A Buyer's Guide

Research from McKinsey and the University of Oxford, based on more than 5,400 IT projects, found that the average project runs 45 per cent over budget and delivers 56 per cent less value than predicted. The Standish Group's CHAOS reports paint an even starker picture: roughly two-thirds of technology projects end in partial or total failure. And when a third party is involved, the odds get worse — Dun & Bradstreet's data shows that 20 to 25 per cent of outsourcing relationships fail within two years, rising to 50 per cent within five.

These are not obscure statistics. They are the lived experience of thousands of UK organisations that chose the wrong partner, signed the wrong contract, or failed to ask the right questions before writing a cheque. If you are evaluating software consultancies right now, this guide is designed to help you avoid joining that majority.

We run a software consultancy ourselves. We have opinions. But this article is not a sales pitch — it is a practical framework you can use to evaluate any firm on your shortlist, including our competitors.

Why this decision is harder than picking most suppliers

Choosing a design agency, accountancy practice, or office supplier is relatively straightforward. You can see previous work, compare standardised deliverables, and switch providers without catastrophic consequences.

Software development is different for three reasons:

1. The work is invisible until it is not. You cannot hold a software product in your hands during the build. You are trusting a team's process, judgement, and communication to deliver something that does not yet exist. This makes it uniquely difficult to assess progress until problems are already embedded.

2. Switching costs are brutal. If a web design project goes sideways, you can take the brand guidelines to another agency and start again. If a software project fails at month four, the new consultancy cannot simply "pick up where they left off." They need to understand the existing codebase, the architectural decisions made (and not documented), and the original business logic. Budget and timeline reset almost completely.

3. Quality is hard to assess without expertise. A non-technical buyer can evaluate visual design, writing quality, or consulting advice. But how do you assess whether the code behind your new platform is maintainable, secure, and performant? This asymmetry gives consultancies enormous room to over-promise and under-deliver.

This means the selection process itself is your primary risk mitigation tool. Get it right, and you dramatically improve your odds of a successful project.

What to look for: green flags

A genuine discovery phase

Any consultancy worth hiring will insist on understanding your problem before quoting a solution. This might be called "discovery," "scoping," or "a technical assessment" — the label matters less than the behaviour. If a firm quotes a fixed price after a single meeting, they are guessing, and the risk of that guess sits with you.

A good discovery phase typically lasts one to four weeks depending on complexity. It should produce a clear document covering: what the system needs to do, who it serves, what integrations are required, what the technical constraints are, and what is explicitly out of scope. That document becomes the foundation of your contract.

Named individuals on the team

Ask who will actually build your product. Not the account manager or the sales director — the developers, designers, and project leads. A reputable consultancy will introduce you to the delivery team before contracts are signed. If they cannot name the individuals or give you a sense of their experience, the team may not exist yet. You could end up with whoever is available when your project starts, regardless of fit.

A portfolio with context

Case studies that say "we built an app for a fintech company" tell you almost nothing. Look for consultancies that explain the problem they solved, the constraints they worked within, the decisions they made, and the measurable outcomes. If you can, speak directly to previous clients — not references the consultancy hand-picks, but contacts you find through LinkedIn or industry networks.

Transparent communication practices

During the sales process, pay close attention to responsiveness. How quickly do they reply? Do they answer questions directly or deflect? Are they honest about what they do not know or cannot do? The way a consultancy communicates before you sign the contract is the best version of how they will communicate during the project. If it is already frustrating, it will only get worse.

Evidence of process

Ask about their development process. You do not need to understand Agile methodologies in detail, but you should hear specifics: how they plan sprints, how they handle change requests, how they test work before showing it to you, and how they manage deployments. Vague answers like "we're flexible" or "we adapt to each client" often mean they have no consistent process at all.

What to avoid: red flags

No discovery, straight to a quote

If a consultancy provides a fixed-price estimate based on a brief conversation or a written specification you provided, be cautious. They either have not understood the complexity or they have padded the estimate so heavily that you are overpaying for certainty. Worse, they may plan to claw back margin through change requests once the project is underway.

The proposal is all technology, no business

Watch out for proposals that lead with technology choices — "we'll build it in React with a Node.js backend on AWS" — without first explaining how the solution addresses your business objectives. Technology choices should follow from requirements, not the other way around. A consultancy that leads with their preferred stack may be optimising for their own efficiency, not your outcomes.

Vague or missing estimates for individual components

A good proposal breaks the work into phases or components with individual estimates. If you receive a single lump sum with no breakdown, you have no way of understanding where the money goes, which components carry the most risk, or where scope could be adjusted to fit budget. Insist on granularity.

No mention of testing or quality assurance

If the proposal does not specifically address how the software will be tested — unit testing, integration testing, user acceptance testing — it probably will not be. Untested software is a liability. Bugs discovered after launch are dramatically more expensive to fix than those caught during development.

Reluctance to share references

Every consultancy has had difficult projects. That is normal. What matters is how they handled them. A firm that refuses to provide references, or only offers curated testimonials on their website, may be hiding a pattern of poor delivery. Ask for references from projects of similar scale and complexity to yours.

Offshore teams presented as local

There is nothing inherently wrong with distributed or offshore development teams. But if a consultancy presents itself as a UK-based firm and then staffs your project primarily with overseas developers without disclosing this upfront, that is a trust issue. Timezone differences, communication barriers, and cultural misalignment are real factors — research consistently cites them among the top causes of outsourcing failure. You deserve to know who is doing the work and where.

Contract structures explained

The contract model you choose materially affects your risk exposure, budget predictability, and flexibility. There are three common structures, each with genuine trade-offs.

Fixed price

You agree a total cost and scope upfront. The consultancy delivers the defined scope for the agreed price.

When it works well: Small, well-defined projects where the requirements are stable and the consultancy has done similar work before. A marketing website with a clear sitemap. A data migration with known schemas at both ends. An integration between two well-documented APIs.

The risk: Fixed-price contracts create a perverse incentive. The consultancy maximises profit by doing the minimum work that satisfies the contract. Any ambiguity in the specification becomes a negotiation. Change requests — which are inevitable in software — become expensive amendments. The consultancy is also likely to have added a risk premium to the price, so you pay more upfront for the certainty.

Protect yourself: Ensure the specification is detailed and unambiguous. Define acceptance criteria for each deliverable. Include a clause for how change requests are handled and priced.

Time and materials (T&M)

You pay for the actual time spent by the development team, typically at agreed day rates. The total cost depends on how long the work takes.

When it works well: Complex or evolving projects where requirements will change as you learn more. Product development where user feedback should shape the roadmap. Projects where speed matters more than cost predictability.

The risk: Without discipline, T&M contracts can run over budget because there is no ceiling. You are also dependent on the consultancy's honesty about how time is spent. It requires trust and active project management on your side.

Protect yourself: Set a budget cap or "not to exceed" figure. Require detailed time tracking and regular reporting. Review burn rate weekly. Define clear sprint goals so you can assess productivity objectively.

Retainer or hybrid

A recurring monthly commitment — often combining a fixed number of development days with flexibility on what those days are used for. Some consultancies offer a hybrid model: fixed price for a well-defined initial phase, then T&M for ongoing iteration.

When it works well: Long-term partnerships where the work is ongoing. Post-launch maintenance and feature development. Situations where you want guaranteed team availability without committing to a single large project.

The risk: You may pay for capacity you do not use in quieter months. The retainer can also create complacency — if the team is guaranteed work regardless of output, the urgency to deliver diminishes.

Protect yourself: Include a rollover clause for unused days, or the ability to scale down with reasonable notice. Set monthly objectives and review performance against them.

Which should you choose?

For most first engagements, a phased approach works best. Start with a fixed-price discovery phase (typically two to four weeks) that produces a clear scope document and technical plan. Then move to T&M for the build, with weekly check-ins, a budget cap, and defined milestones. This gives you the certainty of a defined starting point with the flexibility that complex software projects demand.

How to structure the first engagement to minimise risk

The biggest mistake buyers make is committing too much too soon. A six-month, six-figure contract with a consultancy you have never worked with is an enormous gamble. Instead, structure the relationship to build trust incrementally.

Start with discovery. Pay for a two-to-four-week discovery phase as a standalone engagement. This is your audition period. You will learn how the team communicates, how they handle ambiguity, and whether their technical thinking is sound. The output — a detailed scope document, technical architecture, and project plan — is valuable regardless of whether you continue with the same consultancy.

Set a first milestone. After discovery, agree a first build milestone that delivers something tangible within four to six weeks. A working prototype. A core feature set. An integrated proof of concept. This is not a throwaway exercise — it should be real, deployable work that advances your project. Evaluate the team's performance against this milestone before committing to the full build.

Separate contracts for separate phases. Do not sign a single contract that covers discovery through to launch. Use separate agreements for each phase so you have natural exit points. This protects you and keeps the consultancy motivated to earn the next phase.

Retain ownership of everything. Ensure your contract explicitly states that all intellectual property — code, designs, documentation, infrastructure configurations — belongs to you from the moment it is created. Check that you have access to all source code repositories and cloud accounts throughout the project, not just at handover. If the relationship ends, you should be able to walk away with everything needed to continue without the consultancy's involvement.

A practical evaluation checklist

Use this when comparing consultancies on your shortlist.

Company fundamentals

• How long have they been trading? Check Companies House for accounts and filing history.
• Do they carry professional indemnity insurance?
• What is their team size, and does it match the scale of your project?
• Are they financially stable? Late filings or shrinking revenue are warning signs.

Technical credibility

• Can they show work similar to yours in complexity and technology?
• Do they explain technical decisions in terms of business outcomes?
• Will they walk you through their development, testing, and deployment processes?
• Can they name the specific individuals who will work on your project?

Communication and culture

• How responsive were they during the sales process?
• Did they ask more questions than they answered in early meetings?
• Were they honest about trade-offs, limitations, or things they would not recommend?
• Do they communicate proactively, or only when chased?

Commercial terms

• Is the proposal broken down into phases with individual estimates?
• Is there a defined discovery phase before committing to the full build?
• Do they offer a contract structure appropriate to your project's complexity?
• Is IP ownership clearly assigned to you?
• Are payment terms tied to milestones or deliverables, not just calendar dates?

References and reputation

• Can they provide at least two references for projects of similar scale?
• What do their Glassdoor or Google reviews suggest about internal culture?
• Can you find independent client feedback outside of their curated case studies?

Final thoughts

Choosing a software consultancy is a significant business decision, and the stakes are higher than most procurement exercises. The asymmetry of information between buyer and seller is real, and it favours the consultancy. Your best defence is a structured evaluation process, a phased engagement model, and clear contractual protections.

The consultancies that welcome this level of scrutiny are usually the ones worth hiring. A firm that resists detailed questioning, avoids committing named team members, or pushes for a large upfront commitment before proving their value is telling you something important about how the relationship will work.

Take your time. Ask hard questions. Start small. And remember that the most expensive software project is not the one with the highest day rate — it is the one that fails.

References

1. McKinsey & Company / University of Oxford — Delivering large-scale IT projects on time, on budget, and on value
2. The Standish Group — CHAOS Report: Project failure statistics
3. Flyvbjerg, B. & Budzier, A. — The Empirical Reality of IT Project Cost Overruns, Journal of Management Information Systems
4. HeadChannel — Time and Material vs Fixed Price: Software Development Contracts
5. The Software House — Why Outsourcing Fails: Problems of Outsourcing Software Development
6. WINaTALENT — Why Software Development Outsourcing Fails Most of the Time
7. Crown Commercial Service — Levelling the playing field: The benefits of working with SMEs