Should we build AI in-house or bring in outside help?
There is a measured answer, and it is less flattering to in-house teams than most people expect. Here is the data, plus the honest caveat about who is telling you.
Most operators default to in-house. The team already exists, the budget is already allocated, and handing the work outside can feel like admitting something. Here is what the measurement actually says.
The numbers
MIT's Project NANDA reviewed more than 300 AI initiatives and tracked how many reached production:
- About 67% of engagements with an external partner reached deployment.
- About 33% of internal builds did.
Roughly twice the rate. On time-to-production, the top-quartile external engagements got from pilot to production in around 90 days, where internal efforts commonly ran nine months or more.
The obvious caveat, stated plainly: we are an outside firm quoting a study that says hiring outside firms works better. Go read the report rather than taking our summary of it. We think the mechanism holds up, and you should check it yourself.
Why the gap exists
It is not that internal engineers are worse. It is closer to three structural things.
Nobody's only job is shipping it. Internal AI work is almost always someone's second priority, behind the thing that breaks if they ignore it. Second priorities move at second-priority speed, and a project that takes nine months has nine months of chances to be deprioritised.
The first one is the expensive one. Retrieval quality, evaluation, chunking, when the system should refuse to answer, what to do about the malformed 5% of inputs — all learnable, and learning them on your own production system costs considerably more than having learned them somewhere else first.
Nobody measured the before. An internal team rarely writes down what the process cost before they started, because they are already inside the process. Without that there is nothing to prove at the end, and a project that cannot prove anything does not survive its first budget review.
When in-house is genuinely the right answer
We would tell you to keep it internal if:
- It touches your core product. If the AI feature is what customers buy, the capability has to live with you. Do not outsource the middle of your business.
- You will do this repeatedly. One workflow is a project; ten is a capability. If the second and third are already visible, paying the learning cost once internally is the better trade.
- The data cannot leave, and the compliance cost of clearing an outsider exceeds the cost of learning it yourselves. That is a real situation in health and finance.
- You already have someone who has shipped one. The gap above is largely an experience gap. If you have closed it, those statistics have stopped describing you.
The version we think is actually right
Neither, exactly. For a first project: bring somebody in to do the first one with your team, not instead of them. The measurable work — what it costs now, what it costs after — gets done properly, your engineers watch a working example being built, and the second one is genuinely yours.
That is why our own engagements are an audit first, then either a build or a fractional engineer working inside your team. If we do the job well, the third workflow does not need us.
Either way, start with the measurement
Whoever builds it, write down what the workflow costs today before anybody touches anything. Hours, headcount, vendor spend. That one step separates the projects that survive a budget review from the 95% that quietly stop being mentioned.
Source: MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025" — 52 organisations interviewed, 153 senior leaders surveyed, 300+ initiatives reviewed.