All articles// buying ai

AI product studio vs software agency vs IT consultancy

A software agency sells execution against a specification, an IT consultancy sells process and risk transfer at enterprise scale, and an AI product studio sells a working product built by one team that owns both the model behaviour and the interface. The right choice depends on whether your specification is trustworthy — and for most AI projects, it is not.

The three models are not degrees of the same thing. They are structurally different businesses with different incentives, and the differences show up hardest on AI projects — because AI projects are the ones where the specification you wrote at the start is most likely to be wrong.

The software agency

An agency takes a defined scope and executes it well. You bring designs or a specification, they bring capacity, and the contract is essentially: build this thing.

This is genuinely the right answer when the thing is well understood. A marketing site, a mobile app with known screens, a migration, an integration — an agency will do these faster and cheaper than a studio, because there is no discovery risk to price in.

The IT consultancy

A large consultancy sells governance, scale, and risk transfer. You are buying the ability to run a programme across many stakeholders, to satisfy procurement and audit, and to have a name on the contract that a board recognises. For a multi-year core-systems replacement in a regulated enterprise, that is worth real money.

The cost is layers. Discovery phases, steering committees, and a delivery team that is typically more junior than the people who sold the work. On a two-year programme that overhead amortises. On a twelve-week AI build it is most of the budget.

The product studio

A studio takes a problem rather than a specification and returns a working product. The unit of delivery is a thing that runs, and the first one usually arrives before the contract for the full build is signed.

The reason this shape suits AI work is that AI decisions resist paper. Whether a model can reliably pull the right fields out of your particular documents is answerable in an afternoon with fifty real documents, and not answerable at all in a discovery deck. Studios front-load that: build the ugly working version, let it kill the bad ideas early.

Side by side

AgencyIT consultancyProduct studio
You bringA specificationA business problem and a budgetA problem and real data
They returnThe specification, builtA programme and a planA working product
Billing shapeFixed scope or time and materialsTime and materials, phasedFixed scope per milestone
Best atKnown, well-defined buildsScale, governance, risk transferAmbiguous, judgement-heavy products
Who you talk toA project managerAn engagement leadThe people writing the code
Typical first deliverableA project planA discovery documentA prototype against your data
Failure modeBuilds the wrong spec faithfullyOverhead exceeds the buildToo small for enterprise-scale programmes
The three models compared on what usually matters

A decision rule that actually works

Ask one question: how confident am I that the specification is right?

  1. Very confident, and the work is large and well understood — use an agency, and hold them to the spec.
  2. Confident, but the programme spans many systems, teams, and compliance regimes — a consultancy earns its overhead here.
  3. Not confident, because the product depends on how well a model handles your actual data — use a studio, and insist the first deliverable is something that runs.

The more your project depends on how a model behaves against your real data, the less a written specification is worth — and the more you should buy a working thing instead of a plan.

The hybrid that often works best

These are not mutually exclusive. A pattern we see work well in larger organisations: a studio builds the first working version and the eval harness, proves the use case against real data, and hands a validated, de-risked specification to whoever has the capacity to scale it — an internal platform team or an existing delivery partner.

That sequencing gets you the studio's discovery speed without asking a ten-person team to run a two-year programme. If you want to see the kind of first deliverable that makes this work, our services page describes how we scope an initial build, and the industry pages show the systems that came out of it.

Frequently asked questions

What is the difference between an AI product studio and a software agency?

An agency executes a specification you provide; a studio takes an ambiguous problem and returns a working product. On AI projects the specification is often wrong until it is tested against real data, which is why studios front-load a working prototype instead of a plan.

When should I hire an IT consultancy instead of a studio?

When you need scale, governance, and risk transfer — a multi-year programme across many systems, teams, and compliance regimes, where a recognised name on the contract has real value. The consultancy overhead amortises over a long programme but dominates the budget of a twelve-week AI build.

Can I use a studio and an agency together?

Yes, and it is often the strongest option in a larger organisation. A studio builds the first working version and the evaluation harness to prove the use case, then hands a validated specification to an internal platform team or existing delivery partner to scale.

How do product studios usually bill?

Typically as fixed scopes agreed per milestone rather than open-ended time and materials, so the commercial unit matches the delivery unit — a working thing. Ask any prospective partner to define the scope in writing before work starts.

  • buying AI
  • vendor selection
  • product studio
  • consultancy
// shipped work

The systems behind this article

Production builds from our portfolio that this piece draws on.

Working on something in this space?

Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team — and how fast we can ship.

Start the conversation