The In-House Mirage

You did the responsible thing, or so it seemed. When the board started asking about AI, you didn’t run off and buy some vendor’s black box you’d never control. You had your own people build it, on your own stack, tuned to your business. That was supposed to be the safe, careful, grown-up choice. So why does the demo never turn into a shipped feature with a number next to it?

In August, MIT’s Project NANDA published a study of enterprise AI that landed like a bucket of cold water. Across 300 deployments, 52 executive interviews, and 153 surveyed leaders, 95% of generative AI pilots had produced no measurable return. Thirty to forty billion dollars of spend, and nineteen of every twenty projects couldn’t point to a dollar of P&L. The headlines read it as proof the whole thing’s a bubble. That’s the lazy take. The report is explicit that the failures weren’t about model quality or regulation. They were about approach: tools that never learned from feedback, never fit how work actually flowed, never had a defined problem to solve before someone started building.

Buried a layer down is the number that should change how you spend next quarter. AI systems built with outside specialists reached deployment about twice as often as the ones built in-house: roughly two of three for the partnered builds, one of three for the DIY ones. Same models. Same money. Half the odds. And the only variable that moved was who was in the room.

That gap has a cause, and it isn’t a shortage of smart engineers. It’s the in-house mirage: the belief that because you already employ good people, building your own AI capability is the safe, cheap, controllable option. It looks free, because you’re already paying those salaries. It looks safe, because it’s your team and your code. And the data says it’s the choice most likely to leave you with a slick demo and a hole in the budget.

Think about how you’d actually build a house. You own the land. You’re going to own the deed no matter who swings the hammer. But you don’t hand your sharpest generalist a framing nailer and a stack of tutorials and tell them to frame it, because it’s their first house, and the mistakes go inside the walls where nobody finds them until the roof starts to sag. You bring in a crew that has framed a hundred houses, and you keep the deed. The house is still yours. You just didn’t learn structural framing on the one you have to live in.

Your internal team is framing its first house. They’re good, and they’ve never shipped this particular thing, so they’re solving every hard part for the first time, part-time, wedged between the work they were already hired to do. Nobody in the room has felt where these builds rot. The place where the model’s confidence outruns its accuracy. The workflow it quietly breaks two steps downstream. The edge case that turns a flawless demo into a Saturday support fire. The report’s own diagnosis was that the tools didn’t learn and didn’t fit the workflow. Of course they didn’t. The people building them were learning the workflow at the same time they were building for it.

Here’s the reframe, and it dissolves the whole build-versus-buy argument you’ve been having in the conference room. That MIT split was never really buy versus build. A bought SaaS tool that nobody wires into your process fails just as flatly. The variable that actually moved the odds was whether someone who had already done this was in the room while it got built. The winning 5% didn’t stumble onto a magic vendor. They brought in people who build with this every day, embedded them next to the team that owns the work, aimed the whole effort at one defined outcome, and kept everything that got made. Borrowed reps. Owned result.

That’s the door the binary hides. You don’t have to choose between renting a black box you’ll never truly control and betting the quarter on your team’s first attempt. The third option is to build it with someone who has already made the expensive mistakes, on your stack, pointed at a number you agreed on before anyone wrote a line, and to own the output outright when they walk. Practitioners are already hashing exactly this out in peer forums, asking whether “buy” really beats “build.” It’s the wrong question. The one that predicts the outcome is whether anyone in the room has built one before.

It’s also, not by accident, how we work. When we take a building lane, we’re in your Slack and your codebase, hands on the thing, next to the people who’ll run it after us, and every line stays yours. When we take a coaching lane, we’re putting the reps into your team so the second build is one they can run without us. And before either starts, the free rough map does the one thing 95% of those pilots skipped: it names the specific problem worth solving and the number it should move, in writing, so you’re never again building toward a demo.

So go back to that five-month demo glowing on the big screen. The real question was never whether your engineers are good enough to build it. They probably are, eventually, on their third try, on your dime. The question is whether what they’re building points at a number you set up front, and whether anyone in the room has shipped one before. If the answer to both is no, you’re not being prudent. You’re funding the mirage.