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, with roughly two-thirds of technology projects ending in partial or total failure. When a third party is involved the odds get worse, and 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.

Behind those numbers are thousands of UK organisations that chose the wrong partner, signed the wrong contract, or didn't ask the right questions before writing a cheque. If you're weighing up software consultancies right now, this guide should help you stay out of that majority.

We run a software consultancy ourselves, so of course we have opinions, but we've tried to keep this practical. You can use it to judge 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 usually simpler. You can see previous work, compare like-for-like deliverables, and switch suppliers without it all going badly wrong.

Software development is different for three reasons:

1. You can't see the work until late on. You can't hold a software product in your hands during the build, so you're trusting a team's process, judgement and communication to deliver something that doesn't exist yet. That makes it very hard to judge progress until problems are already baked in.

2. Switching is very expensive. If a web design project goes wrong, you can take the brand guidelines to another agency and start again. If a software project fails at month four, the new consultancy can't just "pick up where they left off", because they need to understand the existing codebase, the architectural decisions made (and not documented), and the original business logic. Your budget and timeline reset almost completely.

3. Quality is hard to judge without expertise. A non-technical buyer can judge visual design, writing or consulting advice, but how do you tell whether the code behind your new platform is easy to maintain, secure and fast? That gap in knowledge gives consultancies a lot of room to over-promise and under-deliver.

So the way you choose a consultancy is the main way you lower your risk, and if you get it right, your odds of a successful project go up a lot.

What to look for: green flags

A genuine discovery phase

Any consultancy worth hiring will want to understand your problem before quoting a solution. They might call it "discovery", "scoping" or "a technical assessment", and whatever the name, what counts is that they actually do it. If a firm quotes a fixed price after a single meeting they're guessing, and the risk of that guess sits with you.

A good discovery phase usually 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 needed, what the technical constraints are, and what's clearly out of scope, and that document becomes the base of your contract.

Named individuals on the team

Ask who will actually build your product, meaning the developers, designers and project leads, and not just the account manager or sales director. A good consultancy will introduce you to the delivery team before contracts are signed. If they can't name the people or give you a sense of their experience, the team may not exist yet, and you could end up with whoever is free when your project starts, whether they fit or not.

A portfolio with context

Case studies that say "we built an app for a fintech company" tell you very little, so 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. Try to find them yourself through LinkedIn or industry networks, instead of relying on references the consultancy hand-picks.

Transparent communication practices

During the sales process, pay close attention to how they respond. Notice how quickly they reply, whether they answer questions directly or dodge them, and whether they're honest about what they don't know or can't do. The way a consultancy talks to you before you sign is usually the best it'll ever be, so if it's already frustrating, it's likely to get worse during the project.

Evidence of process

Ask about their development process. You don't 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've got no consistent process at all.

What to avoid: red flags

No discovery, straight to a quote

If a consultancy gives you a fixed-price estimate based on a brief conversation or a written specification you provided, be careful. Either they haven't understood the complexity, or they've padded the estimate so heavily that you're overpaying for certainty. They may even 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 meets your business goals. Requirements should come first, with the technology chosen to suit them. A consultancy that leads with its favourite stack may be thinking more about its own efficiency than about your outcomes.

Vague or missing estimates for individual components

A good proposal breaks the work into phases or components, each with its own estimate. If you get a single lump sum with no breakdown, you can't see where the money goes, which parts carry the most risk, or where scope could be trimmed to fit the budget, so ask for the detail.

No mention of testing or quality assurance

If the proposal doesn't say how the software will be tested (unit testing, integration testing, user acceptance testing), it probably won't be. Untested software is a liability, and bugs found after launch cost a lot more to fix than ones caught during development.

Reluctance to share references

Every consultancy has had difficult projects and that's normal, so what you want to know is how they handled them. A firm that refuses to provide references, or only offers curated testimonials on its website, may be hiding a pattern of poor delivery. Ask for references from projects of a similar scale and complexity to yours.

Offshore teams presented as local

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

Contract structures explained

The contract model you choose has a real effect on your risk, how predictable your budget is, and how much room you have to change things. There are three common structures, and each one has its own 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, such as a marketing website with a clear sitemap, a data migration with known schemas at both ends, or an integration between two well-documented APIs.

The risk: Fixed-price contracts give the consultancy an odd incentive, because it makes the most profit by doing the least work that still meets the contract. Any gap in the specification turns into a negotiation, and change requests, which always come up in software, turn into expensive amendments. The consultancy has probably also added a risk premium to the price, so you pay more upfront for the certainty.

Protect yourself: Make sure the specification is detailed and clear, define acceptance criteria for each deliverable, and 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 changing projects where requirements will shift as you learn more, product development where user feedback should shape the roadmap, or projects where speed matters more than a predictable cost.

The risk: Without discipline, T&M contracts can run over budget because there's no ceiling. You're also relying on the consultancy being honest about how time is spent, so it needs trust and active project management on your side.

Protect yourself: Set a budget cap or "not to exceed" figure, ask for detailed time tracking and regular reports, and review the burn rate weekly. Clear sprint goals will also help you judge productivity fairly.

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, or times when you want a team that's always available without committing to one large project.

The risk: You may pay for capacity you don't use in quieter months. A retainer can also make a team complacent, because if they're guaranteed work whatever they deliver, there's less pressure to deliver.

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. That way you get a fixed starting point and still have the flexibility that complex software projects need.

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 a huge gamble, so it's better to set things up so trust builds step by step.

Start with discovery. Pay for a two-to-four-week discovery phase as a standalone engagement and treat it as a trial run. You'll learn how the team communicates, how they deal with unclear requirements, and whether their technical thinking is sound. The output is a detailed scope document, technical architecture and project plan, which is useful to you whether or not you carry on with the same consultancy.

Set a first milestone. After discovery, agree a first build milestone that delivers something real within four to six weeks, such as a working prototype, a core feature set or an integrated proof of concept. This should be deployable work that moves your project on and that you'll keep, so treat it as part of the build. Judge the team's performance against this milestone before you commit to the full build.

Separate contracts for separate phases. Don't sign a single contract that covers everything from discovery to launch. Separate agreements for each phase give you natural points to stop, which protects you and keeps the consultancy keen to earn the next phase.

Retain ownership of everything. Make sure your contract clearly states that all intellectual property, including code, designs, documentation and infrastructure configurations, belongs to you from the moment it's created. Check that you have access to all source code repositories and cloud accounts throughout the project, and not only at handover. If the relationship ends, you should be able to walk away with everything you need to carry on without the consultancy.

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 big business decision, and there's more at stake than in most buying decisions. The seller usually knows a lot more than the buyer, which favours the consultancy, so your best defence is a clear way of comparing firms, a phased engagement and good protections in the contract.

The consultancies that are happy with this level of questioning are usually the ones worth hiring. If a firm pushes back on detailed questions, won't commit named team members, or wants a large upfront commitment before proving its value, that tells you a lot about how the relationship will work.

If you're not sure where to begin, take the checklist above into your next few calls, ask the hard questions and start with a small piece of work. It's easy to worry about a high day rate, but a project that fails will cost you far more.

References

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