Should You Build AI, or Just Let It Arrive?

Every leadership team is under pressure right now to have an AI strategy. The board asks about it, competitors claim to have one, and the pressure is real. The problem is what "have an AI strategy" quietly gets mistranslated into on the way to the operating plan: build something. Stand up an AI team, commission a custom tool, own the capability. That translation feels like ambition and initiative, and for the vast majority of property operators, it is the single most likely way to waste money and management attention on AI while ending up behind the companies that did far less.

The uncomfortable claim underneath this piece is that for most property operators, the right AI strategy is not to build. It is to buy the AI that arrives embedded in the systems you already run, and to spend the focus you would have burned on building somewhere it actually creates advantage. That is a less impressive-sounding answer than "we're building our own AI," which is precisely why so few leadership teams reach it, and why the ones who do quietly outperform.

The data on building is not close

This is not a matter of taste, because the outcomes have been measured, and they point one direction. MIT's NANDA research found that AI purchased from specialized vendors succeeds roughly twice as often as AI built internally, with vendor and partnership approaches landing near a two-thirds success rate against roughly one-third for internal builds. Set that next to the broader failure picture, S&P Global found that 42% of companies scrapped the majority of their AI initiatives in 2025, up sharply from 17% the year before. The abandonment is not mainly a technology problem. It is a strategy problem, and building is the strategy that fails most.

The reasons are structural, not a matter of trying harder. A custom AI build competes against companies whose entire business is building that AI, staffed with specialists you would struggle to hire, improving on a release cycle you cannot match. Whatever you build is measured not against doing nothing, but against what those vendors ship next quarter, and against the AI that is being folded directly into the software you already use at no additional effort on your part. The homegrown tool that looks impressive at launch is often behind the embedded alternatives within a year, except now you also own its maintenance, its security, and the team required to keep it alive.

The cost side compounds this. Standing up even a small in-house AI team runs into the high six or seven figures annually before infrastructure. The talent is scarce, engineers command a large wage premium, and hiring and ramp take months. You are committing scarce capital and scarcer management attention to build something that specialized vendors are giving your competitors as a feature. That is not a strategy. It is a status purchase.

Why the instinct to build is so strong and so wrong

If buying is so clearly better for most, why does nearly every leadership team drift toward building? Three forces push in that direction, and each is worth naming because seeing them is most of the defense against them.

The first is the ownership fantasy. Building feels like owning a capability, while buying feels like renting one, and ownership sounds strategically superior. But you do not own an AI capability by building a tool. You own a maintenance burden and a hiring problem, and the "capability" is a depreciating asset in a field moving faster than your release cycle. The thing genuinely worth owning, your proprietary operational data, you already own, and buying embedded AI does not surrender it.

The second is board pressure translated into visible activity. "We have an AI team" is a sentence a CEO can say to a board, and "we turned on the AI features in the systems we already run" is not, even though the second often produces more value at a fraction of the cost and risk. The pressure to look like you are doing something ambitious pushes toward the expensive, visible option over the cheap, effective one.

The third is the demo that looks easy. A prototype that reads a document or answers a question can be stood up quickly and shown to a board in a way that makes building the real thing look like a short step away. It is not. The distance from an impressive demo to a secure, production-grade system that people trust with real decisions is where most internal AI projects quietly go to die, months later, still a prototype, with the engineering reqs still open.

The honest part: sometimes building is right

This would be a dishonest piece if it pretended building is never the answer, and the blanket "always buy" version of the advice is as wrong as the reflex to build. There is a real case for building, and it is worth stating precisely so you can tell whether you are in it.

Build when the AI is your actual competitive core, not a supporting function. If the thing the AI does is the differentiated product you sell, the reason customers choose you rather than a capability that merely helps you run, then owning it can be worth the cost and risk, because you are building the moat itself rather than the plumbing around it. Build, too, when you can genuinely staff it with senior people who have shipped production AI before, not a first-time team learning on your budget, since inexperienced internal builds carry the highest failure rates of all. For most property operators, neither condition holds. AI is a way to run the business better, not the business itself, and the specialized talent lives at the vendors. In that common situation, buying embedded is not the timid choice. It is the correct one, and building is the expensive mistake dressed as ambition.

The decision rule

Reduced to something you can apply, the rule is simple and the default is the opposite of most companies' instinct. Buy AI embedded in the systems you already run, by default. Let it arrive as a feature of the platforms you have already committed to, where it is maintained by the vendor, improves without your effort, and works on the data you already hold. Reserve building for the rare case where AI is genuinely your competitive product and you can staff senior production experience to deliver it.

For everyone else, the strategic act is not building an AI capability. It is refusing to, deliberately, and redirecting that capital and attention to the places where your company actually competes, while letting the commodity intelligence reach you the cheap way, through the software already running your operation. The leadership teams that win with AI over the next few years will not, for the most part, be the ones who built the most. They will be the ones who resisted the pressure to build what they should have simply switched on.

FAQs

Q1. Isn't buying AI just renting a capability we should own?
Building does not give you ownership of a durable capability, it gives you a maintenance burden and a hiring problem, plus a tool that ages quickly in a fast-moving field. The asset genuinely worth owning is your proprietary data, and buying embedded AI does not require you to give that up. For most companies, "owning" a built AI tool means owning its ongoing costs and its obsolescence.

Q2. What does the evidence actually say about build versus buy?
It consistently favors buying for most organizations. MIT's NANDA research found AI bought from specialized vendors succeeds about twice as often as building internally, and S&P Global found the share of companies abandoning most of their AI initiatives jumped to 42% in 2025. The build path carries the higher failure rate, especially for first-time internal teams.

Q3. When is building genuinely the right choice?
In two situations. When the AI is your actual competitive product, the differentiated thing customers buy, rather than a function that helps you operate, so building it means building your moat. And when you can staff the effort with senior people who have shipped production AI before. If neither holds, and for most property operators neither does, buying embedded is the stronger choice.

Q4. Why do so many companies build when the data says buy?
Three pressures: building feels like owning a capability when it mostly means owning a maintenance burden, "we have an AI team" is easier to tell a board than "we turned on features we already pay for," and an easy-looking demo makes a hard production build seem like a short step. Recognizing these pulls is most of what it takes to resist them.

Q5. Doesn't buying embedded AI leave us dependent on our vendors?
You are dependent either way, on your vendors if you buy, and on a scarce internal team and your own release cadence if you build, which is often the more fragile dependency. The relevant question is which dependency serves you better, and for a capability that is not your core product, a specialized vendor improving it continuously usually beats a small internal team trying to keep pace.

Q6. How does this relate to our proprietary data being an advantage?
The two fit together. Your data is the durable asset, and buying embedded AI lets that data be put to work without your having to build the model layer yourself. You do not need to build AI to benefit from your data, you need AI applied to it, and that increasingly arrives inside the systems already holding the data. Building the model rarely adds advantage that the data was not already providing.

Q7. What should we tell the board instead of "we're building AI"?
That you are deploying AI where it creates value fastest and at the lowest risk, which for most functions means adopting it embedded in your existing systems, and reserving custom building for the narrow places where it would create genuine competitive advantage. That is a more defensible strategy than a costly internal build, and the outcome data supports it over the impressive-sounding alternative.

Q8. What is the first step for a leadership team facing this decision?
Before approving any build, ask two questions: is this AI our actual competitive product, and can we staff it with proven production experience. If the answer to either is no, look first at what AI is already available, or arriving, inside the systems you run, and measure a build only against that embedded option rather than against doing nothing. Most of the time the honest comparison ends the build conversation.