This question comes after a different one. *Should we build custom at all, or buy a product?* is build vs. buy, and it's worth settling first. What follows assumes you've decided to build something specific to your business, and the remaining question is who does it.
Four options, and the honest answer turns on two things: whether AI is core to what you sell, and who is operating the system in eighteen months.
The four models
| Model | Ships in | Best when | Fails when |
|---|---|---|---|
| Hire in-house | 4–9 months | AI is core to the product | You need it this quarter |
| Freelancer | Weeks | Scoped, self-contained build | It becomes load-bearing |
| Agency / consultancy | Weeks–months | Defined project, clear handover | Nothing is left behind |
| Embedded team | ~2 weeks to start | You want it built *and* transferred | You want to stay hands-off |
Hiring in-house
The right answer when AI is genuinely core to your product — when the models and the pipelines *are* the thing customers pay for. Then you can't outsource your differentiation, and you shouldn't try.
The cost isn't just salary. It's the 4–9 month reality: writing a spec you may not be qualified to evaluate, competing for scarce senior people, then ramp. And the first hire is the hardest, because a strong AI engineer wants to work near other strong AI engineers — so hire one and you often have to hire two.
It's the wrong answer when you need something in production this quarter, when this is one system rather than an ongoing capability, or when nobody currently on staff can technically evaluate the candidates.
Freelancers
Genuinely good for scoped, self-contained work — a proof of concept, a well-defined integration, a specific model fine-tune. Fast to start, no overhead, and the ceiling on individual talent is higher than people assume.
The failure mode is predictable and it's about continuity, not competence. One person means no code review, a single point of failure, and no coverage when they're unavailable. When the thing they built becomes load-bearing, you discover the operating burden was never anyone's job. If you go this route, insist from day one on the artifacts that make it transferable — evals, a decision log, a runbook — because a freelancer engagement ends more abruptly than any other kind.
Agencies and consultancies
The mainstream answer, and often right: capacity now, a team rather than a person, and someone who has done this before. 95% of enterprise generative-AI pilots deliver no measurable P&L impact, but buying from or partnering with specialised vendors succeeded about 67% of the time — roughly three times the rate of internal builds (MIT Project NANDA, 2025). Partnering works.
The risk is structural rather than moral: a project-shaped engagement ends at a delivery date, and if nothing transfers, you're back at the start when you next need a change. That's Vendor Roulette, and it's the reason to judge an agency by what it leaves behind rather than by what it demos. Ask the nine questions before signing anything.
Embedded teams
The hybrid, and the one we run: senior engineers working inside your systems, on your sprint board, alongside your people — building the thing *and* transferring the capability as they go. Embedded AI Teams are $3,000–$7,500 per engineer per month, and a pod assembles in about two weeks rather than the months a hire takes.
It suits the common middle case: you want production software soon, you expect to own it eventually, and you don't have the internal bench yet. Your team learns by working next to people who've done it, so capability accrues to you rather than to a vendor relationship — which is the forward-deployed argument in one sentence.
It's the wrong choice if you want to be genuinely hands-off. Embedding requires your people's time, and if nobody on your side is participating, you're paying a premium for something a project engagement does more cheaply.
The two questions that decide it
Is AI core to what you sell? If yes, you will hire eventually — the only question is whether you hire before or after your first production system. Building first with an embedded team and hiring into a working system beats hiring into a blank page, because your first hire inherits evals, a runbook, and a codebase instead of a mandate.
Who operates it in eighteen months? Answer this before you choose, not after. Every model can build something; they differ almost entirely in what happens next. A freelancer leaves, an agency's engagement closes, an in-house team is already there, an embedded pod is designed to hand over. If the honest answer is *nobody yet*, then either budget managed operations or pick a model that leaves your team able to run it.
Most mid-market companies get this wrong in the same direction: they choose on build cost when the decision is really about who holds it afterwards. Our full comparison of the three shapes — build vs. buy vs. embed — lays out the tradeoffs including where each one is genuinely the better call.
