AI Consulting Firms vs AI Development Companies: Which Do You Need?

By Ivan Pylypchuk, CEO of SoftBlues. Has led Claude and Gemini implementations for finance, legal and healthcare teams across the UK and Ireland.

The UK had 5,862 AI companies in 2024, earning £23.9 billion between them (DSIT Artificial Intelligence sector study 2024, published 2025). They are not one market. AI consulting firms diagnose and design: they work out what to build, why, and what it is worth. AI development companies build and ship it. Hire a consulting firm when the problem is still unclear, a development company when the specification is settled, and a team that does both when you need a working system inside a quarter.

At SoftBlues, an AI consulting firm working with regulated mid-market companies across the UK and Ireland, we do both halves of that job, so we usually meet a client after they have bought only one of them.

The distinction is not academic. In 2025 the average organisation scrapped 46% of its AI proofs of concept before they reached production, and the share of companies abandoning most of their AI initiatives rose to 42% from 17% a year earlier (S&P Global Market Intelligence, reported by CIO Dive, March 2025). Some of that is healthy experimentation. A good part of it is a mismatch: a strategy deck bought when the company needed working software, or software built to a specification nobody had tested against the business.

Key facts

AI consulting firms sell judgement. Use-case selection, data and risk assessment, target architecture, business case, delivery plan. The output is a decision, not a deployment.

AI development companies sell delivery. Engineers, integrations, evaluation harnesses, production hosting, support. The output is running software.

Pricing models differ more than day rates do. Advisory work is billed as a day rate or a fixed-fee discovery. Delivery is a fixed-price project or a monthly build retainer, with a support fee on top. Market-wide bands sit in our guide to AI consulting costs in the UK.

A fixed-scope discovery is the cheapest way to find out which one you need. Ours runs £10,000 to £20,000 and ends in a costed build plan (our data, indicative, August 2026).

Most mid-market AI work needs both, in sequence: two to four weeks of diagnosis, then eight to twelve weeks of build (our data, August 2026).

The failure modes are opposites. A consulting firm can leave you with a plan nobody can implement. A development company can build precisely the wrong thing, quickly.

Who this is for, and who it isn't

This is for whoever owns operations, technology or the budget at a 50 to 500 person company in the UK or Ireland, choosing a first or second AI supplier, with money to spend and a process that visibly hurts.

Skip it if you want a weekend prototype, if you already run an in-house AI team and only need extra hands (read our comparison of an AI consultant, a consultancy and an in-house hire instead), or if you are shopping purely on day rate rather than on outcome.

What is the difference between an AI consulting firm and an AI development company?

An AI consulting firm is paid to reduce uncertainty. It surveys your processes, ranks candidate use cases by value and feasibility, checks whether your data can support them, names the regulatory constraints, and hands back a prioritised plan with costs and a business case. Good ones also say which ideas to kill. The deliverable is a document and a decision.

An AI development company is paid to produce working software. It takes a specification, builds against it, integrates with the systems you already run (Xero, Sage, Dynamics, SharePoint, a case-management platform), writes the evaluation tests, deploys it, and keeps it alive. The deliverable is a system in production with a support arrangement behind it.

The confusion is understandable, because the labels have drifted. Plenty of development shops now advertise "AI strategy" as a paid discovery phase, and plenty of consultancies keep a small build team so they can demonstrate something. The honest way to tell them apart is not the website. It is the answer to one question: who is accountable when the thing is live and wrong at 2am? A consulting firm's accountability usually ends at handover. A development company's does not.

[!IMPORTANT]

Ask any prospective supplier to show you the last three things they put into production and who supports them today. Advice-only firms will talk about outcomes their clients achieved. Delivery firms will name the systems and the on-call arrangement.

---

AI consulting firms vs AI development companies: the side-by-side

Two rows deserve emphasis. Pricing model is where most budget surprises originate: an advisory day rate has no natural ceiling, whereas a fixed-price build has a ceiling and a change-control conversation. And team shape tells you what you are really getting. If the proposal lists no data engineer and no QA, you are buying advice regardless of what the cover page says.

Book a discovery call before you choose a supplier type. A 30-minute call is usually enough to tell whether your problem needs diagnosis or delivery. You leave with an honest read on which of the two you should be paying for, the likely order of work, and a rough budget band. No deck required. Book a discovery call.

---

Which does your project need?

Work down this table until a row matches. The first match is normally correct.

==Buy diagnosis when the risk is choosing wrong, and buy delivery when the risk is not shipping.== Most companies get this backwards under pressure. Uncertainty feels like a reason to start building something visible, and a clear specification feels like a reason to commission more analysis.

How long each engagement takes

We put production systems live in 90 days at a fixed price, with money back if the proof of concept fails. Live, not in a slide deck. That timetable works because diagnosis is short and deliberately narrow, not because the build is rushed.

Where each one fails, and how to spot it early

1. The consulting firm that never checked your data. A roadmap that assumes clean, structured, permissioned data is a roadmap for a company you do not have. Ask where they inspected actual records, and what they found.

2. The consulting firm with no delivery reference. If nobody can point to a system that resulted from their advice, you are paying for a hypothesis.

3. The development company that agrees with everything. Enthusiasm about your specification on the first call is a warning sign, not a fit signal. Good delivery teams push back on scope before they quote.

4. The development company with no evaluation plan. Ask how they will measure whether the model output is good enough, and what happens when it degrades. If the answer is "we will test it", they have not built AI in production.

5. Either one, pricing by the hour with no ceiling. Open-ended time and materials on a first engagement transfers all the risk to you.

6. Either one, using your project as their first attempt at your sector. In regulated work this is the expensive one.

[!WARNING]

The most common pattern we see is a well-argued strategy document that dies because the supplier who wrote it could not build, and the supplier who could build disagreed with it. Pay for the handover to be somebody's explicit job.

---

What it looks like in a regulated sector

Regulated buyers carry an extra constraint: the supplier has to be fluent in the rules, not just the technology. UK financial services means the FCA and SM&CR accountability, legal means the SRA in England and Wales, healthcare means the CQC in England plus the DCB0129 and DCB0160 clinical-safety standards, and MHRA rules if the software might be a medical device. All of it sits on top of UK GDPR and ICO guidance on AI and data protection. Confirm the specifics with your own compliance team; none of this is legal advice.

One pharmacy operations team came to us with a settled problem statement: dispensing staff were losing hours a day to prescription queries and stock checks across systems that did not talk to each other. There was nothing left to diagnose, so we went straight to a build. We put a working assistant on real operational data and measured handling time on the queries it covered, rather than claiming a company-wide saving. You can read how that was scoped and built in our pharmacy operations assistant case study. It was a proof of concept, not a live national rollout, and we describe it that way on purpose.

Had that same team arrived saying "we want AI in the pharmacy", the right first invoice would have been a two-week discovery, not a build.

Should you hire a firm that does both?

Full disclosure: SoftBlues is deliberately both, so judge this section accordingly.

Doing both removes the handover, which is where a lot of AI money dies. It also removes a useful check. A firm that recommends work it will then be paid to deliver has an obvious incentive, and you should manage it explicitly:

1. Buy the discovery as a separate, fixed-fee piece of work. It should stand on its own even if you then take it to a different builder.

2. Ask for the recommendation you will not like. Every honest discovery contains at least one "do not build this". If yours does not, push.

3. Keep the option to walk. If a discovery only makes sense as a lead-in to that supplier's build, it was a sales exercise.

4. Ask when they say no. We turn work down when the process is not yet stable enough to automate, or when an off-the-shelf tool will do the job. If a supplier cannot describe a recent decline, they take everything.

[!TIP]

A separable, fixed-fee discovery is the practical middle path. You get the diagnosis without committing the build, and you find out how the team thinks before you find out how they code.

For back-office processes where the target is already obvious, you can also start from the delivery end: see how we scope business process automation work.

Questions to ask on the call, and what a good answer sounds like

1. "Which of these two are you, honestly?" Good answer: a clear one, with the boundary named. Bad answer: "we are a full-service AI partner".

2. "What did you last put into production, and who supports it now?" Good answer: a named system, a date, and the support arrangement. Bad answer: a client logo and a percentage.

3. "What will you look at in our data before you recommend anything?" Good answer: specific systems, record volumes, a sample. Bad answer: "we will work with whatever you have".

4. "How will we know the output is good enough?" Good answer: an evaluation set, a threshold, a review loop, and who signs it off. Bad answer: "the model is very accurate".

5. "What is the ceiling on this price, and what triggers a change order?" Good answer: a fixed fee and a written change process. Bad answer: an estimated range with no cap.

6. "What would make you tell us not to do this?" Good answer: two or three concrete conditions. Bad answer: none.

Frequently asked questions

Is an AI consulting firm the same as an AI consultancy?

In practice, yes; the terms are used interchangeably in the UK market. What varies is whether the firm also builds. Judge on delivery evidence rather than on the word in the company name.

Can one supplier do strategy and build without a conflict of interest?

It can, provided the strategy stage is a separable fixed-fee piece of work you could take elsewhere, and the recommendation includes things not to build. Structure it that way and the conflict is manageable.

Which is cheaper overall?

Buying delivery alone is cheaper if your specification is right. If it is wrong, it is the most expensive option available, because you pay for the build twice. A two to four week discovery is usually the cheapest insurance against that.

What if we have already paid for an AI strategy and nothing happened?

Take the two highest-value items to a development company and ask for a three to six week proof of concept on real data. Do not commission a second strategy. Reality tests a plan faster than another plan does.

Do we need a consulting firm to choose between Claude, Gemini and Copilot?

Rarely on its own. Platform choice usually follows the stack you already run: a Microsoft 365-native business often gets further with Copilot, while document-heavy and agentic work tends to suit Claude. Anyone who recommends a platform before looking at your processes is selling a preference.

How do we compare proposals from the two types?

Normalise them first. Ask both to price the same defined outcome, with the same assumptions about data access and integration, then compare total cost to a working system rather than day rates. Three candidates is enough for a first engagement. Our guide to comparing AI vendor proposals and delivery risk sets out the scoring.

---

We are a registered Anthropic Partner Network member and a Google Cloud partner, we run six of our own departments on Claude, and we have delivered 50-plus AI builds. We do diagnosis and delivery, and we will tell you which one you actually need, including when the answer is neither.

If you want a straight read on whether your project needs a consulting firm, a development company, or nothing yet, book a discovery call.