AI consultancy or an in-house AI team?
An honest decision guide from a firm with an obvious interest in the answer. Written to be useful even if you conclude you should hire, because a client who engaged us for the wrong reason churns in six months and tells everyone why.
You are not choosing a supplier. You are choosing where the knowledge lives.
Build-versus-buy gets argued as a cost question and decided as a control question. The useful framing is neither: it is a question about where the durable knowledge about your data, your constraints and your models is going to sit in three years, and how much you are willing to pay in elapsed time to put it there. An in-house team is the only structure that accumulates that knowledge permanently. A consultancy is the only structure that can apply senior knowledge to your problem this quarter. Every serious answer is some sequencing of those two facts.
The dimensions that actually decide it.
No scores and no invented benchmarks, because the honest comparison is qualitative. The third column is the hybrid most enterprises land on once they have run the first use case.
| Dimension | In-house team | Consultancy | Embedded pod (hybrid) |
|---|---|---|---|
| Time before first production model | Hiring cycle, then ramp, then build | Build starts immediately | Build starts immediately, hiring runs in parallel |
| Seniority available on day one | Whoever you can hire and retain | Senior practitioners from the start | Senior practitioners, transferring to your hires |
| Domain knowledge of your business | Deepest, and it compounds | Learned during the engagement | Learned by the pod, retained by your team |
| Cost profile | High fixed, low marginal once loaded | Variable, scoped per engagement | Variable now, converting to fixed |
| MLOps and monitoring ownership | Yours to build and staff | Included in the engagement | Built with you, handed over |
| Key-person risk | Concentrated in a few hires | Absorbed by the firm | Diluted across both |
| Who owns the outcome at 2am | Your on-call rota | The engagement's support terms | Shared, then yours |
| Where it fails | Stalls in hiring, or ships without operations | Dependency, if handover is not contracted | Costs more than either, if run indefinitely |
Which side of the line are you on?
If more than two items in a column describe you, that column is your answer.
- AI is the product, not a capability supporting it
- You have a multi-year pipeline of AI work, not one use case
- Your data or regulatory posture makes external access genuinely hard
- You can credibly compete for senior ML and platform engineers
- The board has patience measured in quarters, not weeks
- You need a result before a hiring cycle could finish
- You have prototypes that never reached production
- You need to know whether a use case is viable before funding a team
- The gap is operations and platform, not modelling
- You want the first system built to a standard your future hires inherit
Four line items missing from most build-versus-buy spreadsheets.
None of these are arguments for hiring us. They are the items that make an in-house business case wrong in either direction if they are left out.
Elapsed time before value
Salary comparisons implicitly assume the team exists. Sourcing, interviewing, notice periods and ramp on your stack all happen before the first commit, and every month of it is a month the use case is not returning anything. Model the delay as a cost, because your CFO already does.
The operations half of the work
A model in a notebook is perhaps a third of the job. Serving under an SLA, monitoring, drift detection, retraining pipelines, audit logging and rollback are the rest, and they need platform engineers rather than data scientists. Teams that budget only for modelling ship a prototype and then stall for two quarters.
Key-person risk
A three-person in-house team is one resignation away from a system nobody understands. That risk is real, insurable only through documentation nobody writes under delivery pressure, and it is the single most common reason a working model quietly goes unmaintained.
The cost of learning on your own data
Some fraction of a new team's first year is spent discovering things about your data estate that an experienced team would have surfaced in the first fortnight. That learning is genuinely valuable and it is genuinely expensive, and it is the item most often left out entirely.
Three situations where we are the wrong call.
AI is your core product
If the models are the thing you sell, that capability has to live inside the company. We can help you stand up the platform and the standards, but building your differentiator on an external team is a strategic error no engagement structure fixes.
You already know the use case works
A validated use case, a business owner and clean data means you do not need a strategy engagement to confirm what you know. Hire the engineers, or take a sprint and skip the audit.
The real blocker is organisational
If the planner will override the forecast, or no one owns the outcome, no model changes anything. That is a mandate problem, and buying engineering to solve it is the most expensive way to not solve it.
What buying-then-building actually looks like.
The sequence that lets both options compound instead of competing, mapped onto the engagements we actually run.
Find out what is real
A fixed-fee readiness audit scores candidate use cases on business value and data readiness independently, and produces an ROI model against a named P&L line. If the honest conclusion is a data remediation quarter before any model work, you learn that for the price of an audit.
Retire the risk cheaply
One scoped use case to a working proof of concept wired to real data, with a clear go or no-go. This is the stage that tells you whether an in-house team is worth recruiting for, and it costs a fraction of finding out eighteen months into a build.
Ship it, then hand it over
An embedded pod takes it to production with MLOps and governance while your permanent hires are recruited and ramped alongside it. Documentation, runbooks and team enablement are deliverables, not goodwill, and the exit is scoped from day one.
Build versus buy, answered.
Over a long enough horizon, in-house is almost always cheaper per unit of output, which is why the honest answer depends on the horizon. A consultancy costs more per month and less per outcome in year one, because you are not paying for the hiring cycle, the ramp, or the models that get abandoned while the team learns your data. In-house wins once you have enough steady-state AI work to keep senior people busy and enough institutional knowledge for them to be productive against. The mistake is comparing a day rate to a salary and stopping there.
The build itself is rarely the bottleneck. Sourcing, interviewing and notice periods for senior machine-learning and platform engineers run to months before anyone writes code, and then there is a ramp on your data, your stack and your compliance environment. If your board has asked for a result this year, that timeline is the constraint to plan around, not the model architecture.
You will if the engagement is structured to make you dependent, and that is a contract question rather than a philosophical one. Ask for documentation and runbooks as named deliverables, insist your engineers sit inside the pod rather than receiving handovers, and put a defined exit in the scope from day one. We include those by default because the alternative is a client who resents us in year two.
That is usually the right answer past the first use case. An embedded pod ships the current thing while your permanent hires are still being recruited and ramped, and the pod's work becomes the codebase and the standards your team inherits. It is the only version of build-versus-buy where the two options compound instead of competing.
Then your gap is probably not modelling. Most teams with data scientists and no production AI are missing platform and operations: serving, monitoring, retraining, CI/CD built for models rather than borrowed from web deployment. That is a narrower and cheaper engagement than a full build, and we will tell you if that is what you actually need.