Over the past decades, the real estate industry has gone through three technological cycles, consistently asking the same question at the wrong level: business intelligence in the 2000s, RPA in the 2010s, and now generative AI. Each time, the industry asks about licensing costs. Two decades of observing these cycles show that the licence fee was never the crucial figure. The relevant metric is how the cost per additional use case develops with the fifth, twentieth, or hundredth implementation.
Most CRE firms still cannot answer this question, which ultimately costs them more than the pure licence fee ever would. The incorrect approach is easy to identify: most firms evaluate the economics of AI as they would traditional enterprise software – by seat cost, contract term, and implementation fee. This framework fails, however, as soon as AI is deployed across a portfolio, because the true cost structure does not lie in the licence.
Instead, it encompasses everything that surrounds the licence: integration, governance, maintenance, and the recurring effort required to keep a rapidly evolving technology up to date. Licence costs are the visible 10 percent; the other 90 percent is the area where the budget truly flows, and almost no one plans for these costs in advance. Traditional CRE platforms are by no means an incorrect investment; they continue to form the operational backbone of many companies. The challenge is that AI introduces new economic realities that go beyond merely purchasing software.
Common Cost Models and Their Pitfalls
Three cost models have become established industry-wide at scale. All three fail in similar ways, just at different points in time. The first model is the purchase of point solutions – for example, one tool for lease abstraction, another for market intelligence, and a separate product for prospectuses. Each tool stands alone. At scale, however, they share no infrastructure. Each requires its own integration, governance, and maintenance. The result is so-called AI islands: real functionality without cumulative benefit. This is a key reason why approximately 95 percent of generative AI pilot projects fail to achieve a measurable business impact. The models work, but each deployment starts from scratch. Consequently, the economics never improve.
The second model is in-house development. Almost every CRE tech team underestimates the same problem here: the actual coding probably makes up 10 percent of the real work. Solutioning – ensuring systems remain current, auditable, and accurate as data changes – accounts for the other 90 percent. This is not a one-off expense but requires continuous operational capability. Companies that get this right build this capability once and reuse it with every new AI workflow, instead of rebuilding the same foundation with each implementation.
The third model involves commissioning a consulting firm or system integrator to carry out the transformation. Conceptually, this model scales with time and personnel – it is billed hourly or per full-time equivalent, meaning the incentive is geared towards more hours rather than faster results. The pattern is consistent: strategy presentations and engineers deployed on-site, a lead time of several months before going live. Industry-wide, large companies average nine or more months to take a single AI use case from pilot to production, while mid-sized firms take about 90 days. This gap is not a capability gap. It arises when a deployment model is billed by the hour instead of by results.
The Paradigm Shift in Cost Considerations
None of these three models answers the question that truly determines the economics of AI at CRE scale: whether the cost per additional use case decreases, remains constant, or increases due to governance sprawl. In a portfolio business, this answer is crucial. A company that handles lease abstraction, prospectus creation, offer management, and market intelligence across dozens of business units does not implement four projects. It implements one capability four times, and the economics only work if the second implementation is cheaper and faster than the first.
Scale also changes the value of a small deviation in accuracy. Small workflows tolerate inaccuracies, as errors are corrected manually. A workflow processing tens of thousands of leases per year cannot; a few percentage points of accuracy directly translate into hours of rework and downstream reporting errors. Large-scale economics are not just the platform cost. They are the costs that a model error rate causes week after week with real portfolio volume, without anyone manually checking every output.
The ongoing change: pricing is per solution, per year, against a measurable outcome – not per token, not per seat, not per hour. This sounds like a commercial detail. However, it is not. Token- and seat-based pricing models penalise precisely those workflows most intensively used in CRE – lease volumes that peak around renewal cycles, demand for prospectuses that surges before a major pitch, or underwriting volumes that fluctuate with deal flow. A pricing model based on constant usage per seat will always appear expensive given the irregular, cyclical volume in the real estate sector.
Outcome-based pricing models tied to a common platform, rather than billing by measured consumption, align better with the portfolio-driven nature of the commercial real estate market. The cumulative effect is easily underestimated until directly observed. The world's leading commercial real estate group, Cushman & Wakefield, started with a single lease abstraction workflow, processing a portion of the approximately 40,000 leases handled annually, and now operates over 15 AI solutions – on a common data and governance layer that works with (not against, not instead of) the company's existing technology structure.
The economic argument is simple: the cost of the next use case should decrease, not reset, and its accuracy should not start from zero. The question is not how much AI costs this quarter. The real question is how much it will cost for the next 10 use cases, or what the error costs will be when use cases are running at real portfolio scale. If the answer is: “about the same as the first case”, then the company has a problem.
