Why “should we just build it ourselves” is usually the wrong question
Why the build vs buy AI decision is usually framed wrong, and the three ownership questions to ask before approving an internal build.
Author
Head of Product & Delivery
Topics
Key takeaways
- The build vs buy AI decision is usually framed as a subscription cost against engineering time you already pay for, which makes building look cheaper than it is.
- That framing leaves out maintenance, the vendor roadmap you stop benefiting from, and the fact that a model API plus a prompt behaves like a finished product for about a month.
- The 95% of enterprise AI pilots with no measurable ROI are mostly fast internal builds that never got funded as infrastructure.
- Build decisions often get made because building is more interesting than running an RFP, and a prototype is a visible, ownable win.
- Ask who owns this in eighteen months and what it costs them to keep it working, before anything gets greenlit.
Every product leader has sat in the meeting where someone asks it. On the surface it sounds like discipline, someone pushing back on a vendor contract, asking the right questions and doing their job and protecting the budget. Usually what’s talking is confidence that hasn’t been tested yet.
Why the question feels smarter than it is
The question frames the decision as a simple trade: buy a tool and carry a subscription cost, or build the equivalent with engineering time you already have on staff. Phrased that way, building almost always looks cheaper, because you’re not adding a new line item, you’re redirecting people you’re already paying.
But that framing leaves out most of what determines the outcome. It leaves out maintenance, which nobody budgets for because it doesn’t show up until six months after launch, when the person who built it has moved teams and nobody else understands the edge cases. It leaves out the vendor’s roadmap, which keeps improving after you sign, while your internal tool stops improving the moment the engineer who built it gets pulled onto something with a deadline. And with AI specifically, it leaves out the fact that “build it ourselves” now often means wiring together a model API and a prompt, which looks like an afternoon of work and behaves like one for about a month, right up until it meets a case the prompt wasn’t written for.
Building almost always looks cheaper, because you’re not adding a new line item, you’re redirecting people you’re already paying.
The pattern is pretty consistent
Teams make this call often enough now that it follows a shape. A team ships an internal AI tool fast on a small budget, it works well enough in the first few weeks to get held up as a win, and then usage grows past what the original build was designed for. At that point it starts needing:
- monitoring
- error handling
- access controls
- someone accountable when the model gives a bad answer to a customer-facing team
None of that was in the original estimate, because the original estimate was really answering “how long to get a demo working” rather than “how long to run this safely at scale”.
The MIT research getting passed around this year, that 95% of enterprise AI pilots aren’t producing measurable ROI, usually gets read as evidence that AI is overhyped. But I read it differently. A lot of those pilots are this exact pattern, a fast internal build that proved a concept and then never got the investment to become a piece of infrastructure, because the team that built it had already moved on to prove the next one. What failed was the absence of a maintenance plan. We’ve written before about why so many AI projects struggle to scale, and the shape is the same every time.
What "build it ourselves" is often optimising for
The build decision often isn’t made on cost grounds at all, even when it’s presented that way. Building is more interesting than evaluating vendors, and a working prototype is a visible, ownable win in a way that “we spent three weeks running a proper RFP” never will be. Engineers like building things and leaders like pointing at things their team built, which are both legitimate motivations that don’t add up to a business case.
The tell is usually in how the decision gets discussed. If the conversation covers total cost of ownership over two years, the headcount required to maintain it, and what happens when the one person who understands it leaves, that’s a real evaluation. If it’s mostly about how fast the prototype came together and how good the demo looked, that’s enthusiasm wearing a business case as a costume. The same thing shows up in architecture, where the difference between AI-native and bolt-on decides whether the thing survives contact with real usage.
If it’s mostly about how fast the prototype came together and how good the demo looked, that’s enthusiasm wearing a business case as a costume.
A better question to ask instead
Replace “build or buy” with “who is going to own this in eighteen months, and what does it cost them to keep it working”. That question forces the maintenance burden into the room at decision time instead of letting it turn up as a surprise later.
In practice, ask three things before greenlighting an internal build over a vendor tool:
- Who is the named owner after the initial build. Not the team, an actual person.
- What is the plan for when the underlying model changes its behaviour or gets deprecated, because it will.
- What does it cost to keep this compliant and monitored rather than just functional, particularly if it ever touches customer data or a regulated decision.
If nobody can answer those three with more than “we’ll figure it out”, what you have is a demo that hasn’t been asked to grow up yet.
We spend a lot of time with product and engineering leaders working through exactly these calls, usually somewhere between the prototype that impressed everyone and the version that has to survive real users. The way we work puts our people inside your team for that stretch, which is where the ownership question gets answered early. If that’s a conversation worth having, let’s talk.
Serar is Head of Product and Delivery at Restive. He works with engineering and product teams to close the gap between strategy and execution.
Frequently asked questions
Should we build or buy AI tools?
Neither answer is right by default. The build vs buy AI decision should be made on total cost of ownership over two years, with the subscription price as only one input. Building looks cheaper because internal engineering time is already budgeted, but that comparison ignores maintenance, monitoring, access controls, compliance and the vendor roadmap you give up. Compare the full cost of running the tool safely at scale against the vendor price, then decide.
What is the real cost of building an AI tool in-house?
The initial build is usually the smallest cost. The ongoing costs are maintenance when the original engineer moves teams, monitoring and error handling once usage grows, access controls, accountability when the model returns a bad answer to a customer-facing team, and rework when the underlying model changes behaviour or gets deprecated. Most internal estimates answer “how long to get a demo working” rather than “how long to run this safely at scale”.
Why do 95% of enterprise AI pilots fail to show ROI?
The MIT figure is often read as evidence that AI is overhyped. A more useful reading is that most of those pilots were fast internal builds that proved a concept and then never got the investment to become infrastructure, because the team that built it moved on to the next proof of concept. The failure point is the absence of a maintenance plan.
What questions should product leaders ask before greenlighting an internal AI build?
Three. Who is the named owner after the initial build. Name a person, not a team. What is the plan for when the underlying model changes its behaviour or gets deprecated. And what does it cost to keep the tool compliant and monitored rather than just functional, particularly if it touches customer data or a regulated decision. If the answers are all “we’ll figure it out”, the build is not ready to be approved.
How do you tell a real build vs buy evaluation from enthusiasm?
Listen to what the conversation covers. A real evaluation covers total cost of ownership over two years, the headcount required to maintain the tool, and what happens when the one person who understands it leaves. Enthusiasm shows up as talk about how fast the prototype came together and how good the demo looked.
Related articles
Real outcomes, for real Australian organisations.
How we built AI-powered personalisation and retail media for one of Australia’s largest supermarket chains.