Why AI Software Projects Fail in CRE (and How to De-Risk a Build) | NextAutomation

If you are reading this, you have probably either lived through a software project that never delivered or you are about to spend money on one and you are nervous. Both are rational. Most AI and software projects in commercial real estate do not fail because the technology cannot do the task. They fail for a small set of predictable, boring reasons that have nothing to do with the model and everything to do with how the build was scoped, gated, owned, and rolled out. This piece names those failure modes so you can recognize them on sight, then lays out how to de-risk a build so the next one actually lands.

The industry backdrop, so you know you are not alone: in JLL's 2025 Global Real Estate Technology Survey of more than 1,500 decision-makers across 16 markets (JLL, October 28, 2025), only 5 percent of firms reported achieving all of their AI goals, and 47 percent met just two or three. Most programs stall. That is not a reason to avoid building. It is a reason to build the way the 5 percent do, which is almost entirely about the parts of the project that are not the AI. All the operator quotes below are de-identified: patterns we hear repeatedly, not a single named firm.

This piece is about why custom AI builds fail and how to de-risk one. If your problem is upstream of that, a pilot that stalls before anything real gets built, the adoption and sponsorship version of this story is why AI pilots fail in real estate.

Six Ways an AI Build Actually Fails

Almost every dead project we get called in to look at traces to one or more of these six. They are not exotic. Once you can name yours, the fix is specific, and it is rarely a better model.

1. Built for the demo, not for the workflow

The most common failure is a system that works beautifully on a clean, hand-picked example and falls apart the first week it meets your real deals. A solo New York investor described exactly this arc. He had self-built his CRM and tooling with an LLM and, in his words, had "pretty much implemented everything." Then he looked at what he actually had: "zero-security HTML code" that "lacks reliability and tracking." It demoed. It could not be trusted with a live deal.

A demo proves the task is possible on one input. A workflow proves the system holds up across the messy variety of a real pipeline: the offering memorandum with a scanned rent roll, the T12 in a format you have never seen, the deal that arrives at 6pm on a Friday. If a build was scoped to impress in a meeting rather than to run every day, it was engineered for the wrong test.

2. No human in the loop where judgment lives

The reliability objection is one of the most consistent things we hear from serious operators. It is not fear of technology; it is a correct instinct that a system making unchecked calls on a multi-million-dollar decision is a liability, not leverage. Projects that try to fully automate a judgment step, an underwriting assumption, a go/no-go screen, a number that lands in an investment-committee memo, tend to get switched off the first time they are confidently wrong, because one bad output at the wrong moment destroys trust in every good one before it.

The failure here is a design choice, not a model limitation. A build that puts a human gate on every judgment step, so the system proposes and a person approves, is both more reliable and more trusted. If you have been burned, there is a good chance the thing that burned you made a call it was never safe to make alone.

3. The data was never ready

A build inherits whatever mess it is pointed at. If your leases, rent rolls, and historical financials live in inconsistent formats scattered across drives, inboxes, and one person's desktop, a system that ran fine on the sample you handed it will stall on the real inputs. This is the failure mode hiding inside the JLL finding that more than 60 percent of investors say they are unprepared to scale AI beyond pilots (JLL, October 28, 2025): the technical half of that unpreparedness is almost always the data.

The trap is that data readiness is invisible during the pitch and unavoidable in production. Nobody demos on the ugly inputs, so the project looks done, ships, and then meets the actual pipeline, where half its inputs need cleanup no one budgeted for. When a build stalls right after go-live, the data is the first place to look.

4. The maintenance orphan

A working system needs a change eventually, and it always needs one: a new document format, a tweaked criterion, a vendor API that shifts under it. If the project shipped with no documentation, no named maintainer, and no plan for who owns it after launch, the first time it needs an update there is nobody to make it, and a live system quietly rots into a dead one. This is how a build that genuinely worked still ends up in the drawer six months later.

Self-built projects are especially exposed here, because the one person who understood the whole thing is often the founder who built it in evenings and then got pulled back to running the firm. Ownership is a decision you make before the first line of code, or you inherit an orphan. Some firms solve it by putting one person in charge of the AI side, a role we describe in the fractional chief AI officer for real estate.

5. The adoption cliff: principals never bought in

A build can be technically perfect and still fail because the people who set direction at the firm will not personally use it. A family-office operations lead put the dynamic plainly: "I'm an okay user. I use it a lot. But the principal who owns the firm and his right hand, they're not interested in it, which you need to be to learn it, and also they don't have the time." A tool that depends on the least-technical, most time-poor person at the firm changing how they work is a tool that will be quietly ignored.

This is a design constraint, not a training problem you can lecture your way out of. If a system requires principals to log into one more place or change a habit they have held for twenty years, it will lose to the habit. The builds that survive are designed so the least-technical person at the firm gets the value without having to become a power user.

6. The discovery-theater trap

The opposite failure to building the wrong thing is spending months and real money studying what to build and shipping nothing. Endless discovery, strategy decks, and readiness assessments feel like progress and produce no working software. A firm can pay for a great deal of analysis about its AI opportunity and still have zero systems in production at the end of it, which is its own kind of burned.

Discovery matters, but only in proportion to a build that follows it quickly. If a project has been in "figuring out the strategy" for a quarter with nothing running, the failure is not a lack of thinking. It is that the thinking never had to survive contact with a real workflow, the only place you learn whether an idea works.

How to De-Risk the Next Build

The good news in all six failure modes is that none of them is a technology problem, which means all of them are avoidable by decision rather than by luck. Here is the framework we use to keep a build from repeating them, deliberately unglamorous because the glamour is exactly what sinks these projects.

Phase the build: prove one workflow end to end, in weeks

Do not commission a platform. Commission the smallest complete workflow that would pay back on its own, and prove it end to end on your real documents before anything else gets built. One operator told us his wish was for something covering "the complete process as much as possible," and that instinct is right for the eventual system but wrong for the first phase, which should be narrow and finished, not broad and half-built. Extracting a T12 and rent roll into your model, or screening inbound deals against your criteria, are the kind of contained wins you can stand up and validate in weeks, not quarters.

Phasing kills the demo-not-workflow failure and the discovery-theater failure at once. You learn whether the idea survives your real inputs early and cheaply, and you have something running instead of a strategy deck. If phase one does not earn its keep on real deals, you have lost weeks, not a budget.

Put a human gate on every judgment step

Design the system to propose, not to decide, everywhere a real judgment is being made. The model extracts, drafts, flags, and ranks; a person approves before anything becomes a decision the firm acts on. This is what makes a system trustworthy enough to keep using, and it directly answers the reliability objection that sinks so many builds. A human-gated system that a firm actually runs beats a fully automated one that got switched off after its first confident mistake.

Getting the gates right also depends on knowing which steps genuinely need a model and which just need dependable automation, because over-automating the wrong step is how builds become brittle. We cover that distinction in whether a tool is real AI or just automation, and it matters here because the safest builds automate the mechanical parts and gate the judgment.

Decide ownership and maintenance before you start

Name the owner before the first line of code. Who maintains this after launch, who they call when a document format changes, and where the documentation lives are questions to answer at the start, not to discover when the system first breaks. A build that ships with a named maintainer, a runbook, and a maintenance plan survives its first required change; one that ships without them is a maintenance orphan waiting to happen, however well it worked on day one. This is also where the build-versus-buy question quietly gets decided, because owning a system means owning the work of keeping it alive, and a vendor absorbing that maintenance is sometimes the better call.

Design adoption for your least-technical principal

Do not design for the enthusiast on the team. Design for the busiest, least-technical decision-maker at the firm, because they are the ceiling on adoption. If the value reaches them without requiring them to learn an interface or change a habit, the system spreads; if it requires them to become a power user, it dies on the adoption cliff no matter how good it is. The right test is not "is this powerful" but "will the person with the least time and interest actually get value from it without effort."

In practice the output has to land where the firm already works, close to zero-friction for the people who matter most. A system that demands principals adopt a new tool loses to the status quo; one that quietly does the work and surfaces a decision to approve wins, because it respects the one thing principals do not have, which is time.

A Checklist Before You Green-Light Anything

If you are about to spend money on a build, or restart one that already burned you, run it against this before you commit:

• Is phase one one workflow, provable in weeks? If the first deliverable is a platform rather than a single finished workflow on your real documents, it is scoped to fail. Narrow it.
• Does a human approve every real judgment? If the system decides anything the firm acts on without a person in the loop, you are building the reliability failure in on purpose. Add the gate.
• Has anyone looked at the real data? Not the sample. The actual leases, rent rolls, and financials in their real formats. If they are a mess, cleaning them is phase one, before any model work. See the state of AI in commercial real estate in 2026 for how far ahead the firms that did this groundwork already are.
• Is there a named owner and a maintenance plan? If nobody owns it after launch, it becomes an orphan. Decide this before you start, not after it breaks.
• Will your least-technical principal actually use it? If adoption depends on the busiest, least-technical person changing how they work, it will not spread. Design for them or expect the cliff.

Every item on that list is a decision, not a technology. The firms that get burned treat a build as a purchase and hope the model carries it; the firms that succeed treat it as deliberate choices about scope, gating, ownership, and adoption, and let the model be the least interesting part.

The Takeaway

AI software projects in CRE do not usually fail because the AI could not do the task. They fail because they were built for a demo instead of a workflow, removed the human from a judgment that needed one, ran on data that was never ready, shipped with no owner, ignored the principals who had to adopt them, or drowned in discovery and never shipped at all. Not one of those is a model problem, which is why reaching for a smarter model almost never rescues a stalled build. De-risking is the same list inverted: phase the build so one workflow is proven end to end in weeks, gate every judgment with a human, decide ownership and maintenance before you start, and design adoption for the least-technical person who has to use it. Do that, and the odds move sharply in your favor, whatever model you start on.