MIT's NANDA project examined hundreds of GenAI deployments inside organizations in 2025 and came back with one finding that should reset the agenda of every investment committee: systems built with an outside party reached successful adoption at twice the rate of systems built in-house.
Twice. Not because the developers outside are smarter, but because of something every CEO already understands: incentives.
Why in-house development stalls
I have run organizations for 25 years, and I have sat through dozens of meetings where the head of IT presented a system "we'll build in-house". I know the script by heart, and it almost always ends the same way. The reasons are structural, not personal:
- The internal team has no real deadline. The project competes against production incidents, regulatory demands and the day job, and it loses every time. "One more quarter" turns into another year.
- It isn't their profession. A corporate IT team is excellent at keeping core systems alive. The AI field turns over every six months - models, tools, ways of working. Anyone who doesn't live in it daily is building on what was true a year ago.
- Nobody is there to say "good enough, ship it". In-house work has no moment of truth against a vendor bound by a contract. The improvements never end, and there is no date that anyone pays a price for missing.
- The project is a political orphan. It belongs to nobody on the executive team, so when features have to be traded off, no one makes the call.
The result shows up in the State Comptroller report of June 2026: 68% of AI projects in Israel are stuck in pilot. A large share of them are in-house builds that nobody dared to kill and nobody managed to finish.
Why an outside party reaches the finish line
The same coin, other side:
- Focus. An outside party is hired for one thing, and doesn't get pulled into core-system incidents.
- A contract with a number in it. When the success metric is signed up front - baseline, target, date - somebody has an economic reason to finish.
- Experience someone else paid for. A person who has built the same kind of system in five organizations has already covered the tuition on the mistakes. You don't have to pay it a second time.
- Speed. Over my career I have watched organizations wait two years for a system from a systems integrator. Today I build systems end to end myself - a national recruitment platform with an intelligent matching engine, a regulatory compliance checker, a voice bot that handles real conversations - in weeks rather than years. That isn't special talent. It is a way of working that uses what AI can genuinely do now, in the hands of someone who does nothing else.
There is also a plain cost calculation. Industry benchmarks put the move from pilot to production at 2.5 to 4 times the cost of the pilot itself, and that is the successful case. In-house development that drags on for a year and a half costs you a full team's salaries, plus everything that team didn't do instead, plus the risk of ending with no product at all. The comparison is never "vendor cost versus internal hours". It is "the cost of a result versus the cost of an experiment".
When to build inside anyway
Twice as often is a statistic, not a law of nature. Three situations make building inside the right call:
- The process is your competitive core. If the algorithm is the product, the capability belongs in-house, because whoever holds it holds the business.
- You already have a product team that ships. Not an IT team - a team that releases to real users every week. An organization like that can absorb another capability. Most organizations in Israel are not that organization.
- The data genuinely cannot leave. Even here, be precise: the right answer is usually an outside build on your own infrastructure, not in-house development. I run client call transcription on a local machine for exactly this reason - the data never leaves the organization, and the person who built it was still a focused outsider.
The model that works: build outside, own inside
Build or buy is a trap, because it offers two bad options: slow in-house development, or permanent dependence on a vendor. There is a third path, and it is the one I put in front of executive teams.
An outside party delivers the first system - fast, against a signed metric, in production. In parallel, they train a small internal team to take ownership: run it, maintain it, extend it. By the time that first system is working and returning money, the organization holds both a result and a capability. That is how the knowledge ends up in-house without paying the learning cost on your first critical project.
Three questions are worth asking any outside party before you sign. What is the last system you built that is running in production today, and where. What metric will you commit to in advance. And what happens on the day I want the keys handed over. Anyone who stumbles on one of the three has just saved you a great deal of money.
That is what I would have demanded as a CEO, and it is what I offer now as an expert who builds.
Want to see what this looks like in your organization? Send me one painful process, and I'll come back to you with a demo.
