A Decision-Making Framework for Real Estate AI
I’ve spent the last 13 years working with real estate technology. First on Wall St. trying to build tools for ourselves that would help us do our job of analyzing markets, valuing properties, and identifying potential risks we might face in the future on multi billion dollar portfolios. For the past 10 years I’ve been at Columbia University building our own internal AI applications for real estate and also working for some of the largest financial and real estate companies in the world on their AI initiatives. I’ve learned a lot through that work, both from the many failures (I like to call them “lessons learned”) and from the successes.
Our work has slowly evolved from “just do it” to a much more sophisticated and intuitive way of evaluating the potential of AI for real estate use cases. Rather than jumping to “a model” because you need to get to “outcomes” (literally the worst thing you can do), taking some time upfront to ask a series of questions can significantly improve the success rate of the projects you choose to pursue, as well as reducing the overall time, cost, and failure rates of AI initiatives.
When we have initial discussions with companies about AI development partnerships, we find that companies don’t know how to answer some of these questions and never even thought about them. I think you’ll find that these are not highly technical ideas (for the most part), but instead bring together a lot of little ideas that help us make better sense of the big ideas.
Companies don’t need more ideas or more “hot proptech startups”
There’s no shortage of ideas for how real estate companies can use AI. Some of them are good ideas, some are so unrealistic they would be funny if the people proposing them weren’t serious. As an industry, we don’t need more ideas. We need to get better at figuring out which ideas are good, which are realistic, and which have no chance of ever being successful.
This article outlines a framework that I developed and that we use in our work at Columbia. Subsequent articles will go into more detail about each one, along with some example use cases that should be helpful in implementing a more rigorous approach to AI evaluation in your firm. This framework and its four categories has considerably increased the clarity of project requirements and given us roadmaps that improve our execution efficiency and efficacy.
Operational or Strategic
It seems that every new startup and product has claimed to be “transformational.” But, in my opinion, very few have even come close to transformation. Understanding the difference between operational and strategic applications helps determine whether the outcome from an initiative will result in an incremental improvement or a transformational improvement. The first thing you need to get clear about is what kind of impact the proposed technology will have on your organization. We define two broad types: operational (automation, efficiency) and strategic (competitive advantage, new capabilities).
Operational Applications
Operational AI improves how existing work gets done. It automates repetitive processes, reduces manual effort, lowers cost, increases speed, and improves consistency. Real estate offers no shortage of candidates for operational tasks. People extract information from leases by hand. Analysts gather the same data from the same systems every month. Employees prepare nearly identical reports, search documents for specific provisions, draft routine correspondence, categorize invoices, reconcile records, and move information between systems that were never designed to talk to each other. These tasks consume enormous time without creating competitive advantage, and modern AI can perform or assist with many of them.
The business case is usually straightforward: fewer hours, higher throughput, lower error rates, more time for work that actually requires judgment. These projects are also comparatively easy to evaluate because both the current process and the desired improvement are reasonably well understood. If twenty employees each spend ten hours a week on a repetitive task, the current cost is known, and if a system reduces that time by seventy percent, so is the benefit. Operational AI is therefore well suited to conventional process improvement discipline: identify the workflow, measure the current state, estimate the implementation cost, and measure the result.
Organizations should look for these opportunities aggressively. In many cases they will produce the fastest and most measurable returns. But they should also be clear about what these projects are and are not. Automating an inefficient process usually does not create competitive advantage (despite what you’re told). If the same software is available to every competitor, whatever advantage exists at the beginning tends to disappear quickly, and the technology eventually becomes the new cost of doing business rather than a source of differentiation.
Strategic Applications
Strategic AI asks a different question. Instead of asking how existing work can be performed faster, it asks whether technology can create new capabilities the organization does not currently have.
Consider an investment company that develops a proprietary analytical system integrating economic, demographic, property, transaction, capital-market, and spatial information across hundreds of markets. The objective is not to reduce the hours analysts spend in Excel. It is to understand relationships between markets that were previously difficult to observe, identify changing economic regimes earlier, model portfolio risk more dynamically, evaluate thousands of potential investments rather than dozens, and let investment professionals test scenarios that would once have required weeks of custom work. That is not automation. It is creating completely new capabilities for the firm.
Identifying whether a proposed project is operational or strategic is important for a few reasons. First, you need to know the magnitude of the outcome. Second, the evaluation process (discussed more below in the ROI section) is very different for each type and firms need to be careful to apply the right evaluation framework to the right kind of outcome. Operational AI allows an organization to perform an existing activity with fewer resources. Strategic AI may give an organization capabilities it didn’t previously have. One improves the economics of the existing business; the other can change the boundaries of how the business operates.
Three Types of Feasibility
Once a firm has an idea of what kind of impact a proposed initiative will have on the firm, they need to move to asking whether the initiative is even feasible. Too often I’ve seen firms jump to trying to “model” and then realize six or twelve months down the road that it’s not going to work. In my opinion, the problems that caused those failures could have been identified in a few days work 90% of the time. We’ve found that three types of feasibility questions give us a much better idea of what we’re dealing with: should we do it, can it be done, and can WE do it?
Value Feasibility – Should We Do It?
Value feasibility has nothing to do with AI. Is this a problem worth solving? Does it occur frequently enough, cost enough, or matter enough? Will anyone actually use the solution? Does it affect cost, revenue, risk, customer experience, investment performance, or competitive position?
AI is unusually dangerous here because the novelty of technology and the immense hype makes mediocre business ideas look more exciting than they are. Suppose a company builds a system that summarizes a particular internal document, and suppose it works beautifully. If that document is produced fifty times a year and takes fifteen minutes to summarize by hand, near-perfect automation creates almost no economic value. Technical success would not make it a good project. By contrast, a difficult analytical capability affecting billions of dollars of investment decisions may deserve substantial investment even if the implementation proves painful. A company should be willing to conclude: yes, we could use AI for this, but it does not matter enough. That may be one of the most valuable outputs an AI strategy process can produce – avoiding bad projects.
This is common in companies that begin by asking where it can use generative AI, or agents, or some startup. That approach tries to find use cases for technology rather than the other way around. A better starting point is deliberately technology-neutral: Where are we losing time or money? Where are we taking risk because our information is inadequate? What decisions would we make differently with better analysis? Only then is it worth asking whether AI is the right instrument. Sometimes it will be. Sometimes conventional software will work better, sometimes redesigning the process will solve the problem, and sometimes the right answer is to do nothing. A disciplined organization should be comfortable reaching all four conclusions.
Technical Feasibility
This section could an entire book on its own. It often requires understanding how the technology works, but there are some fundamental real estate questions that can do much of that same work. There are also three parts to determining technical feasibility: does the data exist, is this a “computational” problem, and can this scale from prototype to production?
Many AI initiatives fail because organizations underestimate the importance of structured, high-quality data. Machine learning systems require large amounts data and that data must be sufficient to solve the proposed problem. Real estate is a “sparse data” industry and many of the proposed initiatives simply lack sufficient data to have any chance of success.
Technical feasibility begins with defining the structure of the problem. You must determine what information is relevant to that problem. For example, a property valuation model may involve inputs such as rents, expenses, macroeconomic indicators, comparable transactions, and submarket characteristics. I recommend you take an “ideal” approach to this step, meaning identify all the data that would be ideal for you to have to make a decision about the value of that property. Then you work backward and determine what you actually have access to. Often you don’t have all the information you would like, so you need to determine whether what you have is enough to properly value that property (or do whatever else you want to do).
If you’re missing too many of the necessary pieces, you won’t be able to automate that process effectively.
The second question is whether the problem can be addressed computationally. If you’re missing data, it’s highly unlikely any computer will be able to give you a good answer. If the data is highly qualitative, subjective, or has a big range, it’s also unlikely you’ll get an answer that is accurate enough to be used for most real estate purposes. The response we often get here is, “Well, can’t AI just figure it out?” No. Just no. AI is mathematics, not magic. AI is likely to give you an answer to whatever question you ask, but it’s up to you to determine how likely that answer will be a good one.
Finally, it takes about 10-12 times the amount of time and cost to develop production level software than it does to develop a prototype. Many firms develop a prototype that works ok or they see a pilot demonstration, then immediately decides to implement it. But a prototype is very different than production level software. For data collection alone, for example, I not only need to write code to collect data, but I must write code to update that data, then I must write more code to monitor any failures in the updating process, then I must write more code to handle those failures that might arise, then I need to write more code for cybersecurity concerns. That simple prototype now becomes infeasible, usually after about six months of trying to scale it. This becomes even worse in larger companies that must integrate across many departments and legacy systems.
Execution Feasibility
Execution feasibility is the question organizations underestimate most often. Many real estate companies have big visions, but no idea what it takes to get to that vision. Something can be valuable and technically feasible and still be unrealistic for a particular company to deliver.
Advanced systems may require some combination of data engineers, machine-learning engineers, infrastructure specialists, domain experts, security professionals, product managers, legal review, and committed business users. They also require ongoing data acquisition, governance, integration with legacy systems, monitoring, model updates, user training, and the ability to retain specialized employees who have many other options. A technically feasible system can be organizationally infeasible.
The fact that a large technology company could build something, given hundreds of engineers and enormous computing resources, establishes something about technical feasibility. But it tells us very little about whether a regional real estate firm should attempt the same thing. The relevant questions are: Do we have the people, and if not, do we know enough to hire the right ones? Can we fund the project through several iterations rather than one? Does leadership understand that early versions may disappoint? Will business units change their processes? And if a key technical employee leaves, does the organization still understand what it owns?
The strongest initiatives pass all three tests, and failure on each test requires a different response. Technically feasible but low value is a solution looking for a problem, and should be abandoned. Valuable but not yet technically achievable should usually be postponed or simplified. Valuable and achievable but beyond the organization's execution capacity is a good idea in the wrong hands — which may argue for a vendor, a partner, or a deliberate effort to build internal capability first. The purpose of the framework is not to eliminate ambitious ideas, but to distinguish ambition from wishful thinking. A quote I once heard is, “I like someone who has vision, but not someone who has visions.”
Resource Matching and Organizational Discipline
Effective vetting requires matching project complexity with available resources. Organizations often approach AI initiatives by fixing budget and timeline constraints before defining the problem. This approach can lead to unrealistic expectations. Instead, firms should determine the requirements of a desired outcome and then assess whether they are willing to commit the necessary resources. Alternatively, if budget and timeline are fixed, the focus should shift to selecting projects that fit those constraints.
Real estate provides an intuitive analogy for this concept. Developing a high-rise building in a major urban market requires significant capital, expertise, and time. Few organizations would attempt such a project without the necessary resources. AI initiatives should be evaluated with the same discipline. However, because technology capabilities are less familiar, organizations often underestimate complexity and overestimate their ability to execute. Developing a structured vetting process helps bridge this gap.
How To Determine Build vs. Buy
Once an organization has determined the value, technical feasibility, and execution feasibility of an AI capability, the next question becomes: where should that capability come from? Technology sourcing is one of the most important strategic decisions in building AI capabilities. Organizations frequently default to external vendors or generic tools without considering whether those solutions align with their long-term competitive objectives. A structured framework for evaluating sources of technology helps ensure that firms invest in the right capabilities and build sustainable advantage.
Broadly, technology sources can be divided into three categories: industry-agnostic tools, internally developed capabilities, and external third-party providers. Each plays a different role within a company’s technology ecosystem and should be used selectively depending on the type of functionality being implemented. Industry-agnostic tools support functions that are necessary for business operations but do not create differentiation. Examples include accounting software, HR systems, and general workflow tools. Because these capabilities are standardized and do not provide competitive advantage, it is typically inefficient for organizations to build them internally. Purchasing established solutions allows firms to focus their resources on more strategic initiatives.
In contrast, internal development should be prioritized for capabilities that are core to how a company competes. These include decision-making systems, investment models, portfolio analytics, and other tools that capture the firm’s proprietary knowledge and strategy. Internal tools embed the nuances of how a company evaluates opportunities, manages risk, and allocates capital. Since competitive advantage depends on doing something better or differently than competitors, relying on external tools limits differentiation. Even highly sophisticated vendor solutions are often sold broadly across the industry, which reduces their ability to create sustained advantage.
External third-party providers play an intermediate role. They are best used to supplement internal capabilities, particularly in areas such as data provision, cloud infrastructure, visualization tools, and other technical components. These providers supply inputs that enhance internally developed systems rather than replacing them. For example, purchasing geospatial data from a specialized vendor may be far more efficient than building that dataset internally. However, the analysis and decision logic built on top of that data should remain internal to preserve differentiation. In this sense, external tools function as building blocks within a larger internally controlled architecture.
When To Use ROI And When To Avoid It
Return on investment (ROI) is one of the most commonly used frameworks for evaluating technology investments, but its usefulness varies significantly depending on the type of capability being assessed. At its most basic level, ROI compares the benefit generated by an investment to its cost. For example, if a firm spends $1,000,000 developing a system that reduces expenses by $100,000 annually, the ROI would be 10 percent. This calculation is often used when organizations must choose among competing uses of capital. However, ROI is frequently applied too simplistically, particularly in the context of artificial intelligence. In reality, ROI involves multiple components beyond direct cost savings, including risk, lifetime value, opportunity cost, and strategic positioning. Some of these elements are measurable, while others are intangible, making ROI analysis more nuanced than it initially appears.
ROI is most appropriate for evaluating operational and automation-focused applications. These projects typically involve well-defined tasks with clear costs and benefits. For example, replacing manual data entry or accounting workflows with software allows organizations to compare subscription costs with labor savings. Similarly, industry-agnostic technologies—such as accounting systems or document processing tools—often have straightforward pricing and predictable efficiency gains. In these cases, ROI provides a useful decision-making framework because both inputs and outputs are relatively stable and measurable. Even when these systems involve significant upfront costs, they often follow a familiar pattern: a large initial investment followed by lower ongoing maintenance expenses. This dynamic resembles real estate development, where construction costs are incurred upfront and operating costs are comparatively smaller.
However, ROI becomes far less reliable when evaluating strategic or internally developed capabilities. These initiatives often involve uncertain timelines, evolving requirements, and indirect benefits. Costs may change as data gaps are discovered or technical challenges arise. Returns are even more difficult to quantify, as they may manifest through improved decision-making, competitive advantage, or risk reduction rather than direct cost savings. Early ROI estimates can therefore create unrealistic expectations, leading organizations to set rigid budgets and timelines that do not accommodate experimentation. In these cases, firms must adopt a more flexible, vision-based approach, recognizing that some investments are necessary to build long-term capabilities even if near-term returns are uncertain.
Another challenge in ROI evaluation is the presence of ambiguous or indirect benefits, particularly when external technologies support strategic initiatives. Data subscriptions, infrastructure tools, or analytics platforms often have well-defined costs but unclear individual contributions to overall performance. It may be difficult to isolate how much value a specific dataset adds to an investment decision or portfolio outcome. Despite this ambiguity, these components may still be essential for building a broader capability. Organizations must therefore avoid rejecting investments solely because ROI cannot be precisely calculated. In many cases, the cost of inaction—failing to develop necessary infrastructure—may outweigh the uncertainty in projected returns. Ultimately, ROI should be treated as one tool among many, applied selectively where appropriate and supplemented with strategic judgment when evaluating complex AI investments.
The Framework Applied
While this framework doesn’t actually build anything, it does significantly improve clarity about what you want you do decide to build, how to do it, and whether or not it makes sense for your firm. We’ve found that spending a little time going through these questions provide tremendous guidance for firms not sure where to start or what to do next.
As mentioned, over the next few weeks I’ll be publishing additional articles that go into more detail on these and other topics in AI development in real estate firms. These include discussions about why real estate is such a difficult environment for AI applications to work in, who is best positioned to make progress with technology, and some more blunt thoughts on why real estate has struggled with technology.