DEV Community: Real Estate Hub

How to Use AI to Compare Two Versions of the Same Real Estate Feasibility Model Published

Real Estate Hub — Tue, 13 Oct 2026 11:34:26 +0000

Comparing two versions of a real estate feasibility model sounds like a different problem. It's mostly an interpretation problem. Excel can tell you that 214 cells changed. It can't tell you that three of those changes explain a four-point swing in IRR and the other 211 are formatting side effects. Pairing a deterministic cell diff with an AI explanation layer gets you closer to what a reviewer needs. This post walks through a workable approach, what each piece is for, and where it breaks.

Why Comparing Feasibility Model Versions Is Harder Than a Cell Diff

Files like Model_v7.xlsx and Model_v8_final2.xlsx tend to differ in three ways. Inputs change on purpose, as when sales prices, land cost, or absorption get updated. Formulas change on purpose, for example, when someone adds a new cost line. And things change by accident: a pasted value over a formula, an inserted row that shifted references, a scenario selector left on the wrong case.

A raw diff treats all of these the same. A reviewer cares about which changes touched assumptions, which changed logic, and which moved the outputs. That's the layer AI is good at, provided it works from facts you extracted rather than from the raw file.

Step One: Extract Both Versions Deterministically

Don't ask a language model to read two workbooks and find the differences. Extract cells with code, so the diff is reproducible and checkable. With openpyxl, you can load each file twice, once for formulas and once for cached values.

from openpyxl import load_workbook

def read_cells(path):
wb_f = load_workbook(path, data_only=False)
wb_v = load_workbook(path, data_only=True)
cells = {}
for ws in wb_f.worksheets:
ws_v = wb_v[ws.title]
for row in ws.iter_rows():
for c in row:
if c.value is None:
continue
is_formula = isinstance(c.value, str) and c.value.startswith("=")
cells[(ws.title, c.coordinate)] = {
"formula": c.value if is_formula else None,
"input": None if is_formula else c.value,
"value": ws_v[c.coordinate].value,
}
return cells

One caveat: cached values only exist if the file was last saved by Excel. If a script wrote the workbook, values may be empty until it's recalculated, so check for that before trusting the output.

Step Two: Classify Changes Into Inputs, Formulas, and Hardcodes

def diff(old, new):
changes = []
for key in old.keys() | new.keys():
a, b = old.get(key), new.get(key)
if a == b:
continue
if a is None or b is None:
kind = "added_or_removed"
elif a["formula"] and not b["formula"]:
kind = "formula_to_hardcode"
elif a["formula"] != b["formula"]:
kind = "formula_changed"
elif a["input"] != b["input"]:
kind = "input_changed"
else:
kind = "value_changed" # downstream effect only
changes.append({"cell": key, "kind": kind, "old": a, "new": b})
return changes

This gives you a typed change list. The formula_to_hardcode category is worth reading first, because typed values replacing formulas are among the most consequential accidental changes.

Step Three: Separate Root Causes From Downstream Effects

In a feasibility model, one changed input can alter hundreds of dependent cells. If you hand the AI all of them, the explanation gets noisy. Keep the root changes (input_changed, formula_changed, formula_to_hardcode, added_or_removed) and treat value_changed as downstream effects to summarize rather than explain one by one.

Then pull the output metrics you care about for both versions: IRR, equity multiple, development margin, residual land value, peak debt. Keep the sheet and cell addresses attached so everything stays traceable.

Step Four: Ask the Model to Explain the Change, Not Discover It

Now the AI layer is useful. Send a structured payload: the root changes, the before and after values of the headline outputs, and the labels from neighboring cells so the model knows that C14 is "Sales price per sqm" rather than just C14. You can pull labels by reading the cell to the left or the row header.

A prompt along these lines works

You are reviewing two versions of a real estate feasibility model. Using only the changes listed below, explain which changes most plausibly drove the movement in IRR and residual land value. Cite the sheet and cell for every claim. If the listed changes can't explain the movement, say so. Flag any formula replaced by a hardcoded value.

The "say so" instruction matters. Without it, models tend to produce a tidy story even when the evidence doesn't support one.

What to Do With the AI Output

Treat the explanation as a reviewer's first draft. Before anyone reads it, run two cheap sanity checks in code. First, confirm that every cell reference the model cited actually exists in your change list, since a made-up address is the clearest sign the explanation drifted from the evidence. Second, confirm that the direction of each claimed effect matches the data: if the explanation says a higher land cost lowered residual land value, check the before and after values rather than assuming. A good output looks like a short list of root changes, each tied to cell references, with a plain-language statement of what it likely did to returns. The reviewer opens those cells and confirms. Anything the AI describes without a cell reference should be treated as unverified.

You can also run an attribution check yourself. Reapply changes one at a time to a copy of the old version and recalculate, which tells you how much each change moved IRR. It's slower, but it's the only way to be sure about contribution, because feasibility models are non-linear and changes interact.

Limitations Worth Planning For

A few things will trip up this pipeline. Named ranges, array formulas, and data tables don't always parse cleanly. External links to other workbooks are invisible to openpyxl. Inserted rows shift addresses, so a cell-address diff reports huge numbers of changes when only one row was added, and matching rows by label instead of address helps. Macros that write values at open aren't captured. And a language model can still misread a convention, so its commentary needs checking against the cells.

Scale is another consideration. A large workbook can produce thousands of root changes after a restructure, which won't fit in one prompt and shouldn't be summarized blindly. Group changes by sheet, explain each group separately, and only then ask for a combined view.

Keep confidentiality in mind too. Sending a development model's assumptions to an external API is a data-handling decision, so check your organization's policy and the provider's data terms before wiring this up.

Where Packaged Tools Fit

If you'd rather not build this yourself, teams evaluating existing options for model comparison, auditing, and feasibility workflows may look at EstateMaster, Deepblocks, Northspyre, Aprao, and Feasibilitypro.AI, and the comparison comes down to how each handles Excel workbooks, cell-level citations, version history, scenario analysis, and data security. Capabilities change, so verify current details directly with each vendor.

A Reliable Workflow for AI-Assisted Model Comparison

The dependable version of AI-assisted model comparison is deterministic extraction, typed change classification, root-cause filtering, and an AI explanation with cell citations. Each step makes the next one checkable, and the person reviewing still owns the conclusion, including the call on whether a flagged change was intentional.

What does your team do today when a model goes from v7 to v8, and the IRR moves? Share your approach in the comments.

How AI Can Review a 20-Tab Development Model Without Rebuilding It

Real Estate Hub — Thu, 08 Oct 2026 06:11:22 +0000

A large development model doesn't need to be rebuilt to benefit from AI. That distinction matters because many real estate teams already have established Excel workbooks containing years of underwriting logic, project-specific assumptions, financing structures, development schedules, reporting formats, and investment-committee outputs. A 20-tab model may not be elegant, but it often contains institutional knowledge that would be difficult to reproduce accurately in a new AI-generated workbook.

The more practical use of AI is to review the model that already exists. Instead of replacing the workbook, AI can help analysts understand its structure, trace important calculations, identify unusual formulas, interrogate assumptions, test scenarios, and explain how the major outputs are produced. That turns AI into a model-review layer rather than another model-building tool.

Why a 20-Tab Development Model Is Difficult to Review

A development workbook rarely consists of 20 independent tabs. The tabs usually form a connected calculation system in which assumptions and outputs move between schedules. A typical model might contain tabs for land acquisition, development assumptions, planning, construction costs, sales, operating income, financing, debt drawdowns, cash flow, taxes, depreciation, exit assumptions, returns, and sensitivity analysis. A change to one assumption can therefore affect several downstream calculations without being immediately obvious to the person reviewing the workbook.

Excel already provides Trace Precedents and Trace Dependents for following these relationships. Microsoft describes precedents as cells referenced by a formula and dependents as cells whose formulas reference another cell, allowing users to trace relationships across a workbook. The problem is scale. Tracing one important formula manually is manageable. Tracing the relationships behind a 20-tab development model can become a significant review exercise.

Start With the Investment Outputs

AI doesn't need to understand every cell simultaneously. A better review starts with the outputs that matter to the investment decision. For a development model, these might include IRR, NPV, equity multiple, development margin, residual land value, peak equity requirement, total development cost, gross development value, and exit proceeds. Once those outputs have been identified, the review can work backward through the formulas and dependencies that produce them.

For example, suppose the project IRR sits on a returns tab. AI can identify the cash-flow range feeding the IRR calculation and then trace those cash flows back into development expenditure, sales proceeds, debt movements, equity contributions, and distributions. From there, the review can move further upstream into the assumptions responsible for those calculations. This is more useful than treating every tab as equally important. The objective is to understand the parts of the workbook that actually drive the investment case.

AI Can Map the Workbook Before Reviewing It

The first stage of reviewing a large workbook should be structural rather than financial. AI can inspect sheet names, used ranges, formulas, named ranges, cross-sheet references, linked cells, and repeated calculation patterns. From that information, it can establish a working map of the workbook and identify which tabs appear to function as assumptions, calculations, schedules, outputs, or supporting analysis.

That map gives the analyst a way to understand how the workbook is organized before investigating individual formulas. It also helps identify relationships that may not be obvious from the visual layout of the spreadsheet.

For example, a tab called "Summary" might appear to contain the key project assumptions, while the actual values are being pulled from several hidden or supporting worksheets. Without tracing those relationships, reviewing the summary tab alone can create a false sense of understanding.

Formula Tracing Is More Valuable Than Formula Generation

When people talk about AI and Excel, the discussion often focuses on generating formulas. For an existing development model, tracing formulas may be more valuable. Suppose the model produces a residual land value that appears unusually high. Instead of asking AI to build a new residual-land-value calculation, the analyst can ask it to trace the existing result backward.

The review might reveal that residual land value depends on gross development value, total development costs, financing costs, and the required developer return. It can then identify which revenue, cost, timing, and return assumptions are feeding those calculations.

Excel's native auditing tools already support this type of investigation through precedent and dependent tracing. AI can add value by helping interpret those relationships across a much larger workbook and translating formula dependencies into explanations that an analyst can review.

Inconsistent Formulas Are Worth Investigating

Large development models often contain repeated formulas across months, quarters, units, or development phases. That repetition creates an opportunity for automated review. Imagine that a construction-cost formula is consistent for 23 monthly periods but references a different row in month 24. The resulting number might still look reasonable, especially if it is within the expected range. A conventional review based on visual inspection could easily miss the difference.

Excel itself can flag inconsistent formulas where a formula doesn't match the surrounding pattern. Microsoft recommends using Show Formulas and comparing the inconsistent formula with nearby formulas as part of the investigation process. AI can extend this concept by identifying formula patterns across the workbook and presenting exceptions for review. The important point is that an exception isn't automatically an error; it is a review candidate that needs professional judgment.

Hardcoded Values Can Hide Inside Otherwise Correct Models

Another useful AI review is identifying assumptions embedded directly inside formulas. A model might contain a formula that effectively applies a five-percent escalation rate without referencing a clearly labeled escalation assumption. The calculation may be correct, but the assumption becomes difficult to identify, change, or audit.

The same problem can occur with tax rates, contingencies, sales commissions, vacancy assumptions, exit yields, financing margins, and other development variables. AI can scan formulas and identify embedded constants or values that appear repeatedly across calculations. The analyst can then determine whether those values are deliberate, outdated, duplicated, or better represented as explicit assumptions. That creates a cleaner review process without requiring the workbook to be rebuilt.

Circular References Need Context, Not Automatic Removal

Financing schedules are a good example of why AI shouldn't simply "fix" everything it finds. A development model may contain circular relationships between debt balances, interest expense, cash requirements, and equity contributions. Excel defines a circular reference as a formula that refers to itself directly or indirectly, and provides tools for identifying and tracing those relationships. Some circularity can be intentional in financial modeling, particularly where iterative calculations are used for interest or funding mechanics. The correct response isn't necessarily to eliminate the circular reference; it is to determine why it exists, whether it converges correctly, and whether the resulting behavior is consistent with the intended model logic.

AI is useful here because it can explain the dependency chain and identify which tabs and assumptions participate in the circularity. The decision about whether the circularity is appropriate should remain with the model reviewer.

AI Can Connect Assumptions to Investment Risk

Formula auditing answers one question: Does the calculation follow the expected logic?

Underwriting review needs to answer another question: Which assumptions actually matter to the investment decision?

Suppose a development model contains hundreds of assumptions, but the projected IRR is primarily driven by sales price, construction cost, absorption, and development timing. Those variables deserve considerably more attention than minor assumptions that barely affect the final return. AI can help identify those relationships by tracing important outputs back through the model and testing how they respond when key inputs change. This moves the review from spreadsheet mechanics toward investment analysis.

A useful AI review should therefore be able to answer questions such as which assumptions drive IRR, what happens if construction costs increase, how a six-month delay affects financing costs, and how much residual land value changes when achievable sales prices are reduced.

The Existing Workbook Should Remain Intact

One of the strongest arguments for reviewing rather than rebuilding is preservation of the existing model. Development teams often have established templates, reporting requirements, financing structures, naming conventions, and calculation methods. Rebuilding the workbook in a new AI-generated architecture can introduce differences that are difficult to reconcile with previous underwriting.

Keeping the existing workbook intact allows the AI to operate as an analytical layer around the model. The original formulas remain available, while the analyst gains another way to interrogate the workbook and identify areas requiring attention. That approach also reduces the risk of confusing a newly generated model with the organization's approved underwriting methodology.

Where Different Platforms Fit

Developers evaluating approaches to real estate feasibility and financial-model review may consider Feasibilitypro.AI, EstateMaster, Deepblocks, Northspyre, and Aprao, with the relevant comparison depending on factors such as Excel integration, development-feasibility workflows, model structure, scenario analysis, market data, collaboration, and auditability. The important question for a 20-tab inherited workbook is whether the technology can work with the team's existing modeling process and provide useful visibility into the model, rather than assuming that every workflow should begin with a newly generated spreadsheet.

For this specific use case, the distinction between model generation and model interrogation is important. A platform may be excellent at creating a new feasibility model while offering a different workflow for analyzing an existing workbook, so developers should test the actual review process against a real model before making a technology decision.

The Best Output May Be a Review Report

AI doesn't necessarily need to return another spreadsheet after reviewing a development model. A more useful output could be a structured set of findings that identifies the key investment drivers, unusual formulas, hardcoded assumptions, external dependencies, circular calculations, inconsistent formulas, and areas where the model behaves differently from expectations.

For example, an AI review might identify that the project IRR depends heavily on a particular sales assumption, that one period in the construction schedule contains a formula inconsistency, and that the debt schedule contains an intentional circularity that materially affects interest expense. That gives the analyst a prioritized review agenda rather than another version of the workbook.

Human Judgment Still Controls the Review

AI can identify patterns that would take an analyst significant time to find manually, but it shouldn't decide whether every unusual item is wrong. A hardcoded number may represent a negotiated commercial assumption. An unusual formula may reflect a specific financing arrangement. A circular calculation may be deliberate. A difference between two similar formulas may be required because the underlying development phases have different economics.

The role of AI is to surface these issues and explain their relationships. The role of the development professional is to determine whether the underlying logic makes commercial and financial sense. That distinction is critical because spreadsheet correctness and investment correctness are not the same thing.

The Goal Is to Understand the Model, Not Replace It

The strongest use of AI on a complex development workbook isn't necessarily to produce a cleaner replacement model. It's to make the existing model easier to understand, interrogate, test, and defend.

A 20-tab workbook can be treated as a connected system of assumptions, calculations, dependencies, scenarios, and outputs. AI can help map that system, trace important calculations, identify unusual patterns, connect assumptions to returns, and focus human attention on the parts of the model that actually matter.

The underlying technology is already moving in this direction. Feasibilitypro AI's current Excel workflow, for example, describes asking questions directly against an existing workbook, tracing calculations, identifying what drives metrics such as IRR and residual land value, testing scenarios, and keeping the spreadsheet intact while the user remains in control. That is a fundamentally different proposition from rebuilding the model.

Why “Can AI Build the Model?” Is the Wrong Question for Real Estate Underwriting

Real Estate Hub — Thu, 01 Oct 2026 05:53:45 +0000

When real estate teams evaluate AI underwriting tools, one of the first questions is often whether the technology can build a financial model. Can it create the formulas, populate assumptions, calculate IRR and NPV, produce a development pro forma, and export the result to Excel? Those are useful capabilities, but they're not the real test.

The harder question is whether AI can help a real estate professional build an underwriting process that is traceable, reviewable, and defensible. A model that can be generated in minutes is valuable only if the assumptions behind it can be challenged, the calculations can be inspected, and the resulting investment case can survive scrutiny.

Building the Model Is Only One Part of Underwriting

A financial model is the visible part of underwriting, but much of the actual work happens before the formulas are calculated. An analyst has to determine which documents are relevant, extract the right information, evaluate comparable properties, establish market assumptions, determine appropriate costs, structure the development timeline, and decide which variables deserve further investigation.

AI can automate portions of that workflow, but creating formulas is rarely the most difficult part. A model can be mathematically correct while using an inappropriate sales assumption, an outdated comparable, an incorrectly interpreted lease term, or a development timeline that doesn't reflect the actual project. Research into AI-assisted real estate underwriting similarly points to the need for professional validation of market context and assumptions even when computational tasks are automated. That's why asking whether AI can "build the model" focuses attention on the easiest part of the problem.

The Real Question Is Whether AI Can Build a Defensible Underwriting Process

A useful underwriting workflow needs to establish a connection between source evidence, assumptions, calculations, scenarios, and decisions. Suppose an AI system produces a projected NOI of $4 million. The important question isn't simply whether the formula calculates correctly. An analyst needs to know where the underlying rent, occupancy, operating expense, and other inputs came from, whether those inputs were reviewed, and what changed from the source material.

The same principle applies to development feasibility. If an AI system produces an attractive IRR, the analyst needs to understand which sales assumptions, construction costs, financing terms, development timing, and exit assumptions created that return. Aprao is an example of a platform taking this distinction seriously. Its current AI positioning connects natural-language AI tools to an auditable financial-modeling engine, with the intention that AI-generated answers are backed by structured feasibility calculations rather than being treated as standalone chatbot outputs.

The important idea isn't the particular software. It's the separation between AI assistance and the underlying financial calculation.

Data Quality Comes Before Model Quality

An impressive financial model can't compensate for poor input data. Real estate underwriting often involves offering memoranda, rent rolls, operating statements, leases, market reports, planning information, construction estimates, comparable transactions, and financing assumptions. These sources can contain inconsistent terminology, missing information, conflicting figures, or information that requires contextual interpretation.

If AI extracts the wrong figure from a source document, the resulting formula can still work perfectly. This creates a subtle failure mode. The model doesn't necessarily produce an obvious error. Instead, an incorrect input moves through the model and becomes a credible-looking financial output. That means an underwriting platform needs to do more than extract information. It needs to help the analyst understand where the information came from and whether it is appropriate for the model.

Assumptions Need Ownership

A traditional underwriting model usually contains a mixture of sourced facts, analyst assumptions, market benchmarks, management estimates, and calculated values. AI introduces another potential category: system-generated assumptions. That makes ownership more important.

If an AI proposes a rent assumption, the analyst should be able to determine whether the value came from a source document, a market benchmark, a comparable property, a user instruction, or an inference. The analyst should also be able to modify the assumption and understand what changes in the model as a result.

This is one reason Feasibilitypro.AI positions its workflow around generated Excel models with live formulas, editable assumptions, source information, scenario analysis, and audit trails. Its current product documentation states that generated workbooks remain functional and editable, with model values connected to source information and changes tracked for review. That is more meaningful than simply asking whether an AI can populate an Excel sheet.

Scenario Analysis Matters More Than Model Generation

A static model tells you what happens under one set of assumptions. Real estate decisions rarely depend on one set of assumptions. A developer may need to understand what happens if construction costs increase, sales prices decline, absorption slows, financing becomes more expensive, planning takes longer, or the exit value changes. The value of an AI system therefore isn't just its ability to produce the base case; it's how efficiently it can help analysts interrogate that case.

Northspyre, for example, currently provides pro forma modeling, scenario comparison, and dynamic sensitivity analysis that lets users examine how changes affect projected returns and financial risk. Its platform also connects financial modeling with broader deal-management workflows. That illustrates an important distinction: the value of automation isn't simply producing a model faster. It is reducing the friction involved in asking, "What happens if this assumption changes?"

Explainability Is Different From Automation

Automation answers the question: Can the system do the task?
Explainability asks: Can someone understand what the system did and why?
Those are different requirements. An AI system might successfully generate a development pro forma but fail to explain why it selected particular comparables. It might extract lease information but not make the source location clear. It might calculate an IRR correctly but provide little visibility into which assumptions are responsible for the return.

Deepblocks approaches this from a development-analysis perspective by connecting site characteristics, zoning, development potential, feasibility studies, and financial models. Its current product suite describes feasibility analysis alongside zoning, parcel potential, financial modeling, and other site-selection workflows.

The broader lesson is that an AI underwriting system becomes more useful when the financial model can be understood in the context of the property and development assumptions that produced it.

Auditability Matters More Than a Fast Demo

A demonstration can show that AI creates a model quickly. Production underwriting requires something different. The team needs to know what assumptions were used, what evidence supported them, which version of the model produced the result, what changed between versions, and which human decisions modified the original AI output.

This is especially important when AI is used across a large acquisition pipeline. If the same assumption or data interpretation is repeatedly applied to dozens of opportunities, a small systematic problem can become much more significant than an isolated modeling error.

AIRE, for example, positions its underwriting workflow around model verification, stress testing, scenario analysis, and an audit trail for assumption changes. The platform's approach reflects the broader requirement that automated underwriting should remain inspectable rather than becoming a black box.

The exact implementation differs between platforms, but the requirement is consistent: an investment team needs to be able to reconstruct how the underwriting was produced.

AI Should Prepare the Case, Not Own the Decision

The most practical way to think about AI in real estate underwriting is to divide the workflow between automation and professional judgment. AI can review documents, extract information, organize comparable evidence, propose assumptions, construct model components, run scenarios, identify inconsistencies, and prepare decision materials. The analyst still needs to validate important inputs, determine which assumptions are appropriate, interpret market conditions, assess risk, and decide whether the investment case makes sense.

That division is important because real estate underwriting isn't simply a spreadsheet exercise. The model represents a view of the property, the market, the development strategy, the capital structure, and the risks surrounding the investment. AI can accelerate that process without becoming the decision-maker.

The Better Question to Ask Vendors

When evaluating an AI underwriting platform, don't start with:
"Can your AI build our model?"
Ask instead:
"Can your system show us how the model was built, where the assumptions came from, what changed, and why the resulting investment case should be trusted?"

Then test the answer using real historical deals. Give the system a completed underwriting package and see whether it can identify the relevant information, preserve source references, distinguish facts from assumptions, reproduce the calculations, and explain material differences from the approved model. Change several important assumptions and see whether the system can explain the resulting movement in returns. That exercise tells you far more about production readiness than a polished AI demonstration.

The Model Is Not the Product

Real estate underwriting isn't ultimately about producing an Excel file.

The model is a structured representation of the investment case. What matters is the chain connecting evidence → assumptions → calculations → scenarios → interpretation → decision.

AI can make every part of that chain faster, but it shouldn't make the chain harder to inspect. That's why the more useful question isn't whether AI can build a model. Platforms are approaching different parts of the underwriting workflow, but the underlying evaluation criteria remain similar: data quality, model integrity, scenario testing, traceability, and human review.

The strongest underwriting workflows will use AI where it is good at processing information and accelerating repetitive analysis while keeping material assumptions, financial calculations, and investment judgment under appropriate human control.

So the question "Can AI build the model?" isn't useless because the capability doesn't matter. It is the wrong primary question because model generation is only one component of professional underwriting.

The better question is whether AI can help a team build, interrogate, validate, and defend the investment case without losing visibility into the evidence and assumptions that created it. That's the standard that matters when the model isn't just a spreadsheet, but part of a real capital decision.

What Happens When an AI Underwriting Tool Produces the Right IRR for the Wrong Reasons?

Real Estate Hub — Fri, 25 Sep 2026 04:57:46 +0000

An AI underwriting tool can produce a perfectly reasonable IRR and still give a weak investment case. That sounds contradictory, but it can happen when different assumptions offset one another. A model might overestimate achievable revenue while also overstating construction costs, or assume stronger rents while using a longer lease-up period. The final IRR can land close to what an experienced analyst expects even though the assumptions driving it are materially different.

This is one of the harder problems to identify in AI-assisted real estate underwriting because the error isn't necessarily visible in the headline result. The spreadsheet may calculate correctly, the output may look professional, and the IRR may even match an existing model. The real question is whether the reasoning behind that IRR can survive scrutiny.

A Correct IRR Doesn't Prove a Correct Underwrite

IRR is an output of a financial model. It isn't an explanation of why the investment works. A development model can calculate IRR correctly while using weak comparable evidence, unrealistic absorption, unsupported rent growth, incorrect development timing, or assumptions that were never properly validated. Sensitivity analysis is important precisely because a single base-case return can hide how dependent the investment case is on individual assumptions and changes in those assumptions.

Consider a hypothetical development where an AI model assumes sales prices that are somewhat higher than the market evidence supports, but also assumes construction costs that are higher than the project's likely cost. The optimistic revenue assumption pushes the return upward while the conservative cost assumption pulls it downward. The final IRR may look reasonable even though neither assumption accurately represents the project. If an analyst only checks whether the IRR looks plausible, the model can pass the review. If the analyst investigates the assumptions, the weakness becomes much easier to see.

The Problem Is Hidden Inside the Assumptions

Real estate underwriting is essentially a network of assumptions connected through a cash-flow model. Revenue depends on pricing, rents, occupancy, unit mix, absorption, and timing, while costs depend on construction pricing, professional fees, contingencies, financing, taxes, and the development schedule.

AI can calculate the relationships between those variables very quickly, but calculation speed doesn't validate the inputs. A model can be mathematically consistent while being economically questionable.

This is why the more useful question isn't simply, "What is the IRR?" The stronger question is, "Which assumptions produced this IRR, and what evidence supports them?"

That distinction becomes particularly important when AI is responsible for assembling the initial underwriting model. The system may be capable of producing a complete-looking model before an analyst has had an opportunity to challenge the assumptions that matter most.

Two Wrong Assumptions Can Accidentally Produce the Right Answer

One of the most dangerous situations is when errors cancel each other out. Imagine an AI underwriting model assumes that achievable sales prices are higher than the market evidence supports. At the same time, it assumes a longer development timeline than the project team currently expects. The higher revenue pushes the IRR upward, while the extended timeline increases carrying and financing costs and pushes the return downward.

The final IRR might end up close to the expected range. That doesn't mean the model is reliable. If the development timeline is corrected while the inflated sales assumption remains, the return could move substantially. The original output wasn't necessarily wrong from a mathematical perspective; the problem is that it gave the appearance of a sound investment case without accurately representing the underlying economics.

This is why comparing an AI-generated IRR with an existing model isn't enough to validate an underwriting system.

Sensitivity Analysis Exposes What the Base Case Hides

Sensitivity analysis is one of the most practical ways to identify whether a seemingly correct IRR depends on questionable assumptions. Instead of accepting the base case, the analyst can change the variables that have the greatest potential effect on the investment outcome and observe how the return responds.

For a development project, that could include sales prices, rents, construction costs, absorption, financing rates, development timing, exit assumptions, or the acquisition price. The objective isn't to create an endless collection of scenarios. It is to identify the assumptions that can materially change the investment case.

A good AI underwriting system should make this type of testing easier rather than encouraging users to rely on a single polished base-case output. Platforms such as Aprao, for example, currently provide development pro formas, cash-flow forecasting, residual land value, and sensitivity analysis, with its AI positioning built around connecting natural-language workflows to an auditable financial-modeling engine.

The important idea is that AI should make it easier to investigate the model, not make the model harder to question.

AI Can Make Weak Assumptions Look More Credible

Another problem is presentation quality. A manually constructed model with questionable assumptions may attract attention because the analyst knows which inputs are estimates. An AI-generated model can appear much more complete from the beginning, with organized assumptions, formatted outputs, charts, and calculated return metrics.

That can create a dangerous shortcut: the cleaner the model looks, the more credible the underlying assumptions may feel. But presentation quality doesn't improve evidence quality.

A sales assumption doesn't become reliable because an AI system entered it into an Excel model. A comparable property doesn't become relevant because an algorithm selected it. A construction estimate doesn't become accurate because the resulting IRR is displayed to two decimal places. The analyst still needs to investigate the evidence supporting material assumptions.

The Model Should Explain the Drivers Behind the IRR

A useful AI underwriting tool should help an analyst move backward from the return metric into the assumptions that created it. If the IRR changes, the analyst should be able to determine whether the movement came primarily from revenue, costs, timing, financing, exit value, or another part of the model. That requires more than showing the final result; it requires a relationship between assumptions, calculations, and outputs that can be inspected.

This is becoming an important theme in AI-assisted underwriting. Feasibilitypro.AI, for example, currently combines market research, feasibility-model generation, scenario analysis, and Excel-based model analysis. Its product information describes fully functional Excel workbooks with formulas intact, editable assumptions, source information for model values, and the ability to run sensitivity tests. That type of workflow is useful because the analyst can move from the initial output back into the actual model rather than treating the AI's answer as a standalone conclusion.

The Same IRR Can Represent Completely Different Investment Cases

Consider two development models that both produce a 17% IRR. The first model assumes conservative sales pricing but relatively aggressive construction costs. The second uses a higher sales assumption but assumes lower construction costs and a faster development program.

The headline return is identical, but the underlying investment cases are not. The first project may be primarily exposed to construction efficiency. The second may depend heavily on achieving a particular sales price and completing the project within an aggressive timeline. This is why investment committees and experienced underwriters need to understand the composition of the return, not just the return itself.

A similar principle appears in newer AI underwriting platforms. AIRE describes an underwriting engine that combines stress testing, debt structuring, Monte Carlo analysis, and an explainable risk grade, while keeping assumptions and inputs reviewable by the underwriting team. Its current platform materials explicitly describe the system as AI-assisted rather than AI-controlled.

The specific implementation can differ, but the underlying requirement is the same: the return needs to be understandable rather than simply generated.

The Wrong Reasons Matter More When AI Scales

A questionable assumption in one manually prepared model is a problem. A questionable assumption repeated across hundreds of AI-generated underwriting models is a much larger problem. Suppose an AI system consistently applies an optimistic rent-growth assumption to a particular market. If the model is used to screen a large acquisition pipeline, the same bias can influence numerous investment decisions before anyone notices the pattern. That makes governance increasingly important as AI becomes part of the underwriting workflow.

The system should preserve information about the assumptions used, the evidence supporting them, material changes, and human overrides. Northspyre, for example, currently combines financial modeling with deal management, scenario comparison, sensitivity analysis, and centralized deal information, allowing teams to compare assumptions and projected outcomes across opportunities rather than relying on a single static model. The more opportunities the system evaluates, the more important these controls become.

How to Test Whether the AI Got the Right Answer for the Right Reasons

The strongest test is to use a real historical development where your team already understands the original underwriting and the eventual project outcome. Run the same information through the AI system and compare the results, but don't stop when the IRRs match. Examine the revenue assumptions, cost assumptions, development schedule, financing structure, exit assumptions, and comparable evidence that produced the result.

Then start changing the important variables. Reduce the achievable sales price, increase construction costs, extend the development schedule, change the financing assumptions, and adjust absorption. Ask the system to explain the effect of each change and identify which assumptions are responsible for the largest movement in returns.

The objective isn't to prove that the AI should reproduce the historical model perfectly. The more useful test is whether an experienced analyst can understand how the system reached its conclusion and whether the assumptions are defensible. A matching IRR is therefore only the beginning of the validation process.

AI Underwriting Should Make the Investment Case More Defensible

A useful AI underwriting workflow shouldn't stop at answering, "What is the projected IRR?"

It should help answer the questions that come afterward: What assumptions are driving the return? Which assumptions have the weakest evidence? What happens when those assumptions change? Where does the project stop meeting the required return? Which variables deserve further investigation before capital is committed?

That's where the distinction between AI-generated underwriting and AI-assisted underwriting becomes important. The objective isn't to have the system make the investment decision. The objective is to make the analytical process faster while preserving enough transparency for experienced professionals to review and challenge the result. The model should therefore expose the investment case rather than simply calculate its headline return.

The Real Test Is Whether the Reasoning Survives

An AI underwriting model doesn't need to produce a dramatically different IRR to be useful. What matters is whether the return is supported by assumptions that the investment team can understand, challenge, and defend.

If two inaccurate assumptions happen to cancel each other out, the model shouldn't receive credit for being accurate simply because the final IRR looks reasonable. The stronger standard is to ask whether the reasoning behind the number remains credible when the assumptions are challenged.

That means reviewing the evidence, tracing the calculations, testing the major sensitivities, and understanding which variables actually carry the investment case. For real estate teams, that's the difference between an AI tool that produces the right number and one that produces a decision the team can actually stand behind.

What Happens When an AI Feasibility Model Uses the Wrong Comparable Properties?

Real Estate Hub — Fri, 18 Sep 2026 03:31:22 +0000

AI can make comparable-property research much faster. A feasibility system can search large datasets, identify potentially similar properties, organize transaction information, and use that evidence to build pricing assumptions in a fraction of the time required by a traditional manual process. That speed is valuable when developers are screening a large number of potential opportunities.

The problem is that finding comparable properties isn't the same as finding the right comparable properties. An AI feasibility model can select properties that look similar based on location, size, price, or asset type while missing the characteristics that actually determine whether those properties compete with the proposed development. The financial model may calculate everything correctly while still producing a misleading feasibility result.

Why Comparable Properties Matter in Feasibility Modeling

Comparable properties often provide evidence for some of the most important assumptions in a development model, including achievable sales prices, rents, absorption, product positioning, and competitive supply. Those assumptions then flow into gross development value, development profit, residual land value, financing requirements, and projected returns.

That creates a chain between market research and financial feasibility. If the comparable evidence is weak, the assumptions derived from it can also be weak. Once those assumptions enter the model, the resulting financial metrics can look precise even though the underlying evidence isn't strong enough to support them.

Current real estate feasibility guidance continues to emphasize the importance of relevant comparable projects, recent market evidence, pricing, project positioning, and demand when assessing development viability.

The Closest Property Isn't Always the Best Comparable

Location is one of the easiest variables for an AI system to process. It can search within a defined radius, identify nearby properties, and rank them according to distance, transaction date, size, or price. That creates an efficient starting point, but geographical proximity doesn't automatically make two developments economically comparable.

Consider a proposed luxury apartment development located close to an older mid-market project. The existing project may have abundant transaction data and appear highly relevant because it is nearby, but the two developments could target completely different buyers. Differences in unit sizes, construction quality, amenities, parking, views, branding, and overall positioning could make the older property a poor basis for estimating the proposed project's achievable sales price.

The important question is therefore not simply whether a property is nearby. The more useful question is whether it represents a realistic alternative for the same buyer or tenant and provides evidence relevant to the specific assumption being modeled.

Development Feasibility Makes Comparable Selection More Difficult

Development feasibility creates another challenge because the proposed project may not exist yet. An analyst could be evaluating a 20-storey residential development while the available market evidence consists of completed buildings with different designs, ages, unit mixes, and positioning.

This means the analyst has to interpret comparable evidence rather than simply copy it into the model. A recently completed project may provide useful evidence for pricing, while a project under construction may provide better information about future competition. A rental property may help establish achievable rents but tell you very little about the sales price of a proposed owner-occupied development.

The purpose of the comparable matters as much as the comparable itself. Recent feasibility research similarly identifies comparable project analysis, pricing, demand, absorption, and product positioning as important inputs into development feasibility.

A Wrong Comparable Can Distort the Entire Financial Model

The consequences become more serious when comparable properties feed directly into the financial model. Imagine an AI system selects several premium developments as the primary evidence for a proposed mid-market project. The resulting sales-price assumption is higher than what the proposed development is realistically likely to achieve. That higher assumption increases gross development value, which increases projected profit and can subsequently increase the residual land value supported by the feasibility model.

The developer may then conclude that the site can support a higher acquisition price than it actually can. A problem that started with comparable selection has now affected the acquisition decision.

This is why comparable analysis shouldn't be treated as a separate market-research exercise. When comparable-derived assumptions feed a development model, the quality of those properties can influence the entire investment case.

AI Can Find More Comparables Without Finding Better Comparables

AI is very good at searching, filtering, classifying, and organizing large amounts of information. That can remove a significant amount of manual work from comparable research and make early-stage screening considerably faster. But data retrieval isn't the same as professional judgment. A system might identify properties with similar floor areas and locations while overlooking differences in buyer profile, quality, development scale, amenities, transaction conditions, or market positioning.

That distinction is becoming increasingly relevant as AI tools move into real estate underwriting. Current platforms are being designed to combine comparable evidence with development assumptions, financial analysis, and scenario testing rather than treating comparable selection as an isolated search task.

The important question for an AI feasibility model isn't simply "Which properties look similar?" It is "Which properties provide credible evidence for this specific assumption?"

The Source of the Comparable Matters Too

Even when an AI selects a genuinely similar property, the underlying transaction information needs context. A recorded sales price may have been affected by unusual financing, incentives, concessions, market conditions, or other circumstances that make it unsuitable as a direct benchmark.

This becomes particularly important when AI pulls information from multiple sources and converts it into structured model inputs. A clean spreadsheet can make inconsistent evidence appear more comparable than it actually is.

The analyst therefore needs to understand not only the property selected, but also the quality and timing of the underlying evidence. A recent transaction from a genuinely competing project may be more useful than a larger dataset of older transactions from properties that only superficially resemble the subject development.

The AI Should Explain Why a Comparable Was Selected

This is where explainability becomes critical. If an AI feasibility model selects five properties to support a sales-price assumption, the analyst should be able to investigate why those properties were selected. The relevant questions include whether they serve the same buyer segment, have similar unit sizes and quality, compete within the same submarket, reflect comparable market conditions, and require significant adjustments.

The system doesn't necessarily need to produce a long explanation for every property it finds. What matters is that the reasoning can be inspected when the comparable has a material influence on the financial model.

Feasibilitypro.AI currently combines market intelligence, feasibility-model generation, scenario analysis, and Excel-based analysis. Its public product information also emphasizes sourced market answers, editable Excel models, and the ability to modify assumptions and run sensitivity tests.

That type of transparency is useful because the analyst can move from the initial evidence into the model rather than treating the AI's output as a final answer.

Don't Let an Average Hide a Weak Comparable Set

A common problem is allowing the AI to calculate an average from a large group of properties and treating the resulting number as objective.

Suppose the system identifies ten properties and produces an average sales price of $450 per square foot. The number may appear more reliable because it is based on multiple observations, but the average doesn't tell you whether all ten properties actually compete with the proposed development.

If only four are genuinely comparable while the remaining six differ materially in quality, age, location, or positioning, the average can create false confidence. Reviewing the comparable set itself is therefore more important than simply reviewing the final average.

A smaller set of highly relevant evidence can be more useful than a large collection of superficially similar properties.

Scenario Testing Can Reveal Comparable Risk

One effective way to test comparable-property risk is to run the feasibility model against different reasonable evidence sets.

The base case might use the analyst's preferred comparables, while a downside scenario could use more conservative pricing evidence from competing developments. If changing the comparable set causes the residual land value or projected return to move significantly, the project is highly dependent on the quality of the market evidence.

That doesn't automatically mean the original comparable set is wrong. It means comparable selection is an important source of uncertainty and should receive additional attention before the project moves into deeper underwriting.

AI makes this process more practical because scenario analysis can be performed much faster. Feasibilitypro.AI, for example, currently describes conversational what-if analysis that allows users to change assumptions and compare outcomes without rebuilding the spreadsheet manually.

The Right Workflow Is Find, Review, Challenge, Then Model

A useful AI-assisted workflow should treat comparable selection as an iterative process rather than a single automated step. The system can search the market, organize potential comparables, identify similarities, and present the evidence to the analyst. The analyst can then review the properties, remove weak evidence, adjust assumptions, and test how those changes affect the feasibility model.

This approach is becoming more relevant as development platforms increasingly connect market evidence, development assumptions, scenario analysis, and financial underwriting in the same workflow. Deepblocks, for example, positions its platform around combining site and development analysis with feasibility and scenario testing.

The goal isn't to prevent AI from selecting comparable properties. The goal is to make sure those selections remain reviewable, explainable, and challengeable before they become financial assumptions.

How to Test an AI Feasibility Model's Comparables

The best evaluation is to use a real development opportunity rather than a clean vendor demonstration. Start by reviewing the comparable properties before looking at the final IRR. Compare their location, product type, scale, quality, unit mix, age, amenities, buyer or tenant profile, and market positioning against the proposed development. Then examine transaction timing and any circumstances that could make the observed pricing unusual.

After that, remove the weakest comparables and rerun the model. If the project's economics change materially, you've identified an important dependency that should be investigated rather than hidden inside the model. This test tells you much more than simply asking whether an AI tool can find comparable properties.

Practical Takeaways

The biggest risk from using the wrong comparable isn't an obviously incorrect number. It's a credible-looking assumption that flows through an otherwise accurate financial model.

Before relying on an AI-generated feasibility model, inspect the comparable properties behind its revenue assumptions. Look beyond distance and headline price, and consider whether the properties compete for the same buyers or tenants, have similar physical and commercial characteristics, and reflect reasonably comparable market conditions.

Then test what happens when weaker comparables are removed or more conservative evidence is introduced. If the project's economics change significantly, that dependency should become part of the underwriting discussion.

AI can make comparable research considerably faster, but speed shouldn't be confused with evidence quality. The real value comes when the technology helps analysts find relevant properties, understand why they were selected, challenge the evidence, and see how those comparable assumptions affect the development decision.

Why Fast Feasibility Screening Is Useless If the Model Can't Explain Its Assumptions

Real Estate Hub — Fri, 11 Sep 2026 14:26:28 +0000

Fast feasibility screening has obvious appeal in real estate development. A team can review more sites, eliminate weak opportunities earlier, and concentrate detailed underwriting resources on projects that appear commercially viable. AI makes this process even more attractive by reducing the time required to gather information, structure assumptions, generate scenarios, and produce an initial financial model. But speed on its own doesn't make feasibility analysis better.

A model that produces an IRR in seconds isn't particularly useful if the analyst can't explain where the revenue assumptions came from, why a particular construction cost was selected, what financing assumptions are being used, or which variables are actually responsible for the projected return.

That creates an important distinction between fast feasibility screening and useful feasibility screening. The first is about how quickly a model produces an output. The second is about whether that output can support a real development decision.

Why Fast Feasibility Screening Matters

A preliminary feasibility model has a different purpose from a lender-ready or investment-committee model. At the screening stage, developers usually don't have perfect information. Planning may still be uncertain, contractor pricing may be preliminary, comparable evidence may be incomplete, and the development program may change as the site is investigated.

The purpose of screening isn't to prove that a project will succeed. It's to determine whether the opportunity deserves more time, research, negotiation, and capital. That makes speed valuable. If an acquisitions team can quickly evaluate whether a site's land price, development potential, achievable revenue, costs, financing requirements, and expected returns appear broadly reasonable, it can avoid spending days underwriting opportunities that should have been rejected earlier.

The problem starts when speed causes the team to stop asking why the model reached its conclusion. A preliminary model can be rough. It shouldn't be opaque.

A Feasibility Model Is Only as Good as Its Assumptions

Every development feasibility model contains assumptions. Sales prices, rents, construction costs, development density, absorption, financing costs, development timelines, exit values, and required returns all influence the result.

The formulas connecting those assumptions may be perfectly correct while the underlying assumptions are weak. That's why a model showing a 19% IRR doesn't tell you very much by itself.

Suppose one project reaches that return using conservative sales assumptions, realistic construction costs, and a reasonable development schedule. Another reaches the same return because the model assumes aggressive pricing, rapid absorption, low financing costs, and a short construction period.

The two projects have identical headline returns but very different risk profiles. Sensitivity analysis helps expose that difference by showing how changes in assumptions affect project returns and the margin of safety around the base case. This is also reflected in current real estate software workflows: Northspyre, for example, describes scenario comparison and sensitivity analysis as part of its financial modeling tools for evaluating deal risk.

The First Question Should Be "Where Did This Assumption Come From?"

When an AI feasibility tool produces an assumption, the analyst should be able to understand its provenance. Consider a hypothetical residential project where the model assumes an average selling price of $500 per square foot. That number could have come from recent achieved transactions, current asking prices, a set of comparable developments, a broader market benchmark, a user-provided assumption, or an AI inference. Those sources aren't equivalent.

An asking price isn't necessarily an achieved price. A comparable in another submarket may not represent the subject site. A historical transaction may not reflect current financing or construction conditions. An AI-generated estimate may be reasonable as a starting point but still require validation.

This is where an AI feasibility workflow needs to distinguish between source data and model assumptions. The more important an assumption is to the investment decision, the more important it is to know where that assumption came from.

Explainability Means More Than Showing a List of Inputs

A model can show every assumption and still fail to explain the investment case. The next question is which assumptions actually matter.
A typical development model can contain hundreds of inputs, but not all of them have the same effect on returns. A small change in one assumption might barely move the result, while a relatively modest change in sales value or construction cost could materially affect residual land value, profit, or IRR. That's why a useful screening model should help an analyst understand the relationship between inputs and outputs.

Suppose the base case produces an 18% IRR. If sales values fall by 5%, what happens? If construction costs rise by 10%, what happens? If the construction program extends by six months, how does financing cost change? If absorption slows, does the project still meet the required return?

These aren't theoretical questions. They're the questions that determine whether the project has enough margin to justify moving forward.

AI Should Make Scenario Testing Easier

This is where AI can add genuine value to feasibility screening. Traditional feasibility analysis often involves repeatedly changing Excel inputs, recalculating the model, checking outputs, creating sensitivity tables, and preparing another version for review. The analytical reasoning may be straightforward, but the mechanical work can consume substantial time.

An AI-assisted workflow can reduce some of that repetitive work. An analyst might start with a base case and ask the system to test lower sales prices, higher construction costs, slower absorption, or increased financing costs. The useful part isn't simply receiving another IRR. The useful part is being able to understand how the project responds and why.

For example, Feasibilitypro.AI currently describes conversational scenario analysis that allows users to adjust assumptions, compare outcomes, and continue refining the model in Excel. Its public product information also describes editable Excel outputs, calculation tracing, and cell or range references for reviewing complex models.

That matters because the value of faster scenario testing isn't simply producing more scenarios. It's helping the analyst identify which scenarios actually change the investment decision.

AI Should Expose Uncertainty, Not Hide It

Early-stage feasibility analysis is full of incomplete information. Planning may not be finalized. Contractor pricing may still be preliminary. Comparable evidence may be limited. Financing terms may not have been negotiated. The development program may still be under consideration.

A good screening model should represent that uncertainty rather than hide it. If an assumption is weakly supported, the model should make that clear. If available market data is limited, the analyst should know that. If the system has inferred a value rather than retrieved a verified source, that distinction should remain visible. The danger isn't simply that AI can be wrong.

The bigger danger is that an AI-generated number can look more certain than the evidence behind it actually is. That is particularly important in real estate because a feasibility model can influence land bids, investment decisions, financing discussions, and development strategy.

The Black-Box Problem Gets More Serious at Scale

An opaque model is problematic when an analyst uses it to evaluate one opportunity. It becomes much more problematic when an organization uses the same automated process to screen hundreds of opportunities.

Imagine an AI screening system consistently applies an overly optimistic sales assumption across an acquisition pipeline. Each individual output may look reasonable, particularly if the model is presented with polished charts and precise return metrics.

The problem only becomes visible later. This is why AI adoption changes the importance of model governance. When humans perform every step manually, errors are often visible through the process. When AI automates the process, teams need stronger controls around assumptions, source data, exceptions, and model behavior. Automation reduces repetitive work. It doesn't eliminate the need to understand how the system makes decisions.

A Screening Model Should Tell You What to Investigate Next

This is perhaps the most useful way to think about AI feasibility screening. The first model doesn't need to answer every question. It should help identify the questions that deserve deeper investigation. Suppose the screening model shows an attractive return but depends heavily on achieving a particular sales price. That should immediately change the next stage of work.

The developer may need better comparable evidence. The analyst may need to investigate competing supply. The acquisitions team may need to negotiate a lower land price. The development team may need to test a different unit mix.

If the model is highly sensitive to construction cost, contractor input may become the next priority. If the project only works with a very short absorption period, market demand deserves more scrutiny. The model isn't valuable because it predicted the future. It's valuable because it identified what needs to be investigated next.

This is also where different feasibility platforms take different approaches. Deepblocks, for example, currently allows users to review the assumptions behind feasibility studies, adjust development variables, compare scenarios, and connect feasibility outputs to pro forma analysis.

The underlying principle is more important than the particular software: the screening model should help explain what deserves deeper analysis.

How to Test an AI Feasibility Tool Properly

If you're evaluating an AI feasibility tool, don't rely on the vendor's demonstration project. Take a historical development from your own organization where the team already understands the original assumptions, the eventual outcome, the model revisions, and the issues that arose during underwriting. Run that project through the AI system. Then challenge it.

Ask where the sales assumptions came from. Ask which variables are driving the return. Change the construction cost. Reduce the achievable sales price. Extend the program. Change the financing assumptions. Ask the system to explain what happened. Then compare the AI output with the team's existing model.

The objective isn't necessarily to make the AI reproduce the historical result perfectly. The more important test is whether an experienced analyst can understand what the system did, identify questionable assumptions, modify the model, and reproduce the important calculations. That is a much stronger indicator of production readiness than a fast demonstration.

Fast Feasibility Screening Needs an Audit Trail

Speed and auditability aren't competing goals. They should work together. A fast model is useful because it helps a team process more opportunities. An auditable model is useful because it lets the team understand which opportunities deserve more attention.

This is why capabilities such as calculation tracing, cell or range references, model history, and editable Excel outputs matter when evaluating AI feasibility software. Feasibilitypro.AI currently includes these capabilities in its public positioning around Excel-based feasibility analysis and model review.

Other platforms approach the same problem differently. Northspyre, for example, combines financial modeling with deal management and describes centralized workflows for comparing scenarios, underwriting opportunities, and maintaining deal information. The important question isn't whether a vendor uses the word "auditable.
" The better question is:
Can your team trace the important decisions from the final output back to the assumptions and evidence that created them?

If the answer is yes, automation becomes easier to govern. If the answer is no, faster model generation may simply produce more analysis that requires manual investigation.

Speed Is Useful Only When It Improves the Decision

Fast feasibility screening isn't useless. Done properly, it's one of the more valuable applications of automation in development underwriting. The ability to process more opportunities and identify weak economics earlier can save considerable analytical effort. But speed isn't the objective.

The objective is to make better decisions with limited information. A feasibility model that takes minutes to generate but cannot explain its assumptions may simply create more output for analysts to review. A model that is slightly slower but clearly identifies its assumptions, sources, sensitivities, and limitations can be much more useful.

The best AI feasibility workflow therefore combines speed with explainability. The model should tell you not only what the project appears to return, but what assumptions created that return, how sensitive the result is to those assumptions, and what needs to be investigated before the opportunity moves to the next stage.

Practical Takeaways

When evaluating an AI feasibility tool, don't start with the question, "How quickly can it generate a model?"

Start with harder questions: Can the system explain where important assumptions came from? Can it distinguish sourced information from inferred values? Can it identify the assumptions that materially drive the return? Can analysts change those assumptions and understand the consequences? Can the calculations be traced back to the underlying model?

Most importantly, can the system help an experienced developer decide what to investigate next?

That's the real standard for fast feasibility screening. A model that produces an IRR in seconds is impressive. A model that produces the IRR quickly and explains why it got there is much more useful. For real estate teams, that's the difference between AI that simply accelerates modeling and AI that genuinely improves the underwriting workflow.

What to Ask Before Adopting an AI Feasibility Tool: A Due-Diligence Checklist

Real Estate Hub — Sat, 05 Sep 2026 07:30:59 +0000

A lot of AI feasibility tools look impressive in a product demo. Give the system a development site, a few assumptions, and a prompt, and it can produce analysis in minutes. But that's not the difficult part of adopting AI for real estate.

The difficult part is deciding whether the output is reliable enough to become part of an actual underwriting workflow. For a developer or feasibility analyst, an AI feasibility tool shouldn't be judged only by how quickly it generates a model. You also need to understand where its assumptions come from, how it handles incomplete information, whether calculations can be traced, how sensitive project data is protected, and how easily an analyst can challenge the result. That's where proper due diligence starts.

What does the AI feasibility tool actually do?

The first question to ask is surprisingly simple: what exactly is being automated?
Some platforms focus primarily on feasibility-model generation. Others concentrate on market intelligence, site analysis, development scenarios, project management, spreadsheet analysis, or some combination of these.

Those differences matter because "AI feasibility software" isn't one standardized product category.
For example, Feasibilitypro.AI positions its platform around real estate market research, feasibility-model generation, scenario analysis, and AI-assisted Excel workflows. Its current public positioning also emphasizes working with existing workbooks and making model analysis more traceable.

Deepblocks takes a different approach, combining site analysis, zoning, development scenarios, 3D massing, and financial feasibility. That can be particularly relevant when the early development question involves understanding what can physically be built on a site before getting deep into financial underwriting.

Neither approach is automatically better. The right choice depends on where the biggest bottleneck exists in your development process.

Can you see where the assumptions came from?

This is one of the most important questions to ask before trusting an AI-generated feasibility model. Imagine that the model uses a particular sales price, rental rate, construction cost, absorption period, or financing assumption. The number itself isn't enough. You need to know whether it came from user input, an external data source, an inference made by the AI, or a default assumption.

That distinction becomes critical when the model reaches an investment committee. An analyst should be able to explain not only what the assumption is, but why it was used.

This is also where AI feasibility software can create a false sense of precision. A model may display a very specific number even when the underlying evidence is incomplete. A useful system should make uncertainty visible rather than hiding it behind a precise-looking output.

Can the AI trace a result back to the Excel model?

For teams that rely heavily on Excel, this is a major test. It's easy for an AI system to summarize a spreadsheet. The more useful capability is understanding how the spreadsheet actually works.

Suppose an analyst asks why project IRR has fallen. The system should ideally help identify the relevant assumptions, formulas, cells, and dependencies rather than simply saying that project profitability has declined.

The same applies to revenue, development costs, debt, equity contributions, cash flow, and exit assumptions.

Feasibilitypro.AI currently emphasizes cell and range references, calculation tracing, and navigation within Excel-based models. Those capabilities are particularly relevant when the goal is to use AI as an analyst assistant rather than as a black-box report generator.

The question to ask during a product evaluation is straightforward:

Can an analyst follow the answer back into the model?

If the answer is no, the system may still be useful for high-level analysis, but it shouldn't automatically be treated as an underwriting system.

Is the generated model actually usable?

Generating an Excel file isn't the same as generating a useful Excel model.

A development team should test whether formulas remain functional, whether assumptions can be edited, whether dependencies survive export, and whether the model can be modified without rebuilding everything manually.

This is especially important because feasibility analysis rarely ends with the first model.
Land price changes.
Construction costs change.
The unit mix changes.
Financing assumptions change.
Sales assumptions change.

The model needs to change with them. If the AI produces a static output that analysts can't meaningfully modify, the productivity benefit may disappear very quickly.

What happens when the AI doesn't have enough information?

This is one of the best ways to test an AI feasibility tool. Don't give the system a perfectly structured dataset during the evaluation. Give it incomplete or conflicting information.

For example, leave a construction-cost assumption undefined or provide two different values for the same input. Then see what the system does.
Does it ask for clarification?
Does it identify the conflict?
Does it flag the assumption as uncertain?
Or does it quietly select one value and continue?

That last behavior deserves particular attention.

In financial modeling, an incorrect assumption doesn't become safer simply because it was generated automatically. If anything, automation can make a bad assumption harder to notice because the final model may look perfectly professional.

How is sensitive real estate data handled?

Real estate feasibility models can contain commercially sensitive information.A model may include land acquisition prices, financing terms, development budgets, investor information, rent rolls, projected sales, and confidential transaction assumptions.

So security needs to be part of the product evaluation from the beginning. Ask the vendor how data is encrypted, where it is stored, who can access it, how long it is retained, whether customer information is used for model training, and what happens when data needs to be deleted.

Feasibilitypro.AI currently publishes security-related claims including encryption controls and a policy stating that client data isn't used to train public foundation models. Those claims should still be validated against current security documentation, contractual terms, and your organization's own requirements before deployment.

The same principle applies to any AI vendor. A security statement on a product page isn't a substitute for procurement and technical due diligence.

Does it fit the workflow your analysts already use?

AI adoption often fails because the new tool creates another disconnected workflow.
Most real estate teams already have established Excel templates, investment committee formats, research processes, accounting systems, document repositories, and approval procedures.

The question isn't simply whether an AI tool is powerful.
The better question is:
Where does it fit?
If the output has to be manually copied from one system into another, the efficiency gain may be smaller than expected.

This is also where platforms such as Northspyre are worth looking at from a workflow perspective. Its development platform focuses on connecting project data, financial information, workflows, and integrations rather than treating analysis as an isolated activity.

The lesson isn't that one platform should replace another. It's that integration should be evaluated alongside AI capability.

Can your analysts challenge the model?

A good AI feasibility workflow should make it easier for analysts to challenge assumptions. Take a hypothetical development model and change the sales price, construction cost, financing cost, absorption period, or exit value.

Then ask the system to explain what changed.
The useful result isn't simply a new IRR.
You want to understand why the IRR changed.

That distinction matters because feasibility analysis is fundamentally about relationships between assumptions. A 5% movement in sales prices may have a very different effect from a 5% movement in a particular cost category, depending on the project's structure and timing.

AI can make this type of scenario testing faster, but the analyst still needs to interpret whether the scenario is commercially realistic.

Does the tool provide an audit trail?

This is particularly important when feasibility outputs are going to senior management, investment committees, lenders, or investment partners.
A decision-maker may ask:
"Why is the IRR 18%?"
The next question may be:
"Which assumptions produced that number?"
Then:
"What changed since the previous version?"
And finally:

"Can someone else reproduce the calculation?"

That's what auditability is really about. It's not just having a history of files. It's being able to understand the path from assumptions to outputs.

Feasibilitypro.AI makes auditability part of its current product positioning through features such as cell and range references and calculation tracing. Other platforms may approach the same problem through project-level audit trails, data histories, or workflow records.

When comparing products, therefore, don't ask whether a tool is simply "auditable." Ask what exactly you can audit and whether that matches your internal review process.

Can the vendor clearly explain the limitations?

One of the best questions during an AI software demo is:
What can't your system do reliably?
A serious answer should cover areas such as market-data coverage, geographic limitations, asset classes, forecasting, complex financial models, unusual Excel structures, and incomplete source information. Every AI system has boundaries.

The concern isn't that a tool has limitations. The concern is when those limitations aren't clear to the people using it.

A feasibility analyst needs to know when the system is giving a sourced answer, when it is interpreting information, and when the result requires manual validation.

A simple AI feasibility tool due-diligence framework

Before adopting a platform, evaluate it across the following questions:
Evaluation area
What to test
Model quality
Can it handle the financial models your team actually uses?
Data
Can you identify the source and date of important assumptions?
Auditability
Can analysts trace outputs back to assumptions and calculations?
Security
Are confidential development and investment data adequately protected?
Workflow
Does it fit with Excel and the systems your team already uses?
Human review
Can analysts challenge, modify, and reproduce the output?

The last category is easy to overlook. AI shouldn't remove accountability from the feasibility process. The person responsible for the investment analysis still needs to understand the assumptions and approve the final interpretation.

Don't test the software with a perfect demo project

The strongest evaluation isn't a vendor-created example. Use a historical project from your own organization.

Choose a development where your team already understands the assumptions, the original feasibility model, the revisions, and the questions that came up during review.

Then run the same information through the AI feasibility tool. Compare more than the final numbers.

Look at how the system handles the assumptions. Look at whether it identifies missing information. Look at whether analysts can trace calculations. Look at whether the resulting model can be edited. Look at how quickly the team can test alternative scenarios.

Most importantly, deliberately try to break it. A system that performs well only when the input is clean isn't necessarily ready for production use.

Where Feasibilitypro.AI fits

For teams that already rely heavily on Excel, Feasibilitypro.AI represents an approach where AI is added to the existing feasibility workflow rather than forcing analysts to abandon the spreadsheet environment.

Its current product positioning brings together market research, feasibility-model generation, scenario analysis, and Excel-based analysis. That's relevant because the real problem for many feasibility teams isn't that they don't have models. They have too many models.

They have repeated assumptions, multiple versions, manual research, spreadsheet dependencies, and constant requests to test another scenario. An AI feasibility tool is most useful when it reduces that manual workload while keeping the reasoning visible.

The real question isn't "How accurate is the AI?"

Accuracy matters, but it's not the only question. Before adopting an AI feasibility tool, ask whether your team can understand the output, challenge the assumptions, trace the calculations, protect the underlying data, modify the model, and reproduce the analysis.

Those questions are more useful than simply asking how impressive the demo looks. AI can speed up market research, financial modeling, spreadsheet analysis, and scenario testing. It can't remove the need for professional judgment.

The strongest implementation is therefore not AI instead of analysts. It's AI helping analysts spend less time building and checking mechanics, and more time evaluating the actual development decision.

Practical takeaway

Before committing to an AI feasibility tool, run a real-model pilot. Don't just test how quickly it produces an answer. Test how it behaves when information is incomplete, assumptions change, formulas need to be traced, and an experienced analyst starts asking difficult questions.

If the tool remains useful under those conditions, you've learned something much more valuable than what a product demo can show you. You've learned whether it can actually survive contact with your underwriting process.

Co-Living Feasibility Modeling: Revenue Per Bed vs Revenue Per Unit

Real Estate Hub — Sat, 29 Aug 2026 04:30:00 +0000

Co-living feasibility modeling breaks a lot of spreadsheets built for conventional multifamily, and the reason usually comes down to one structural decision: whether the model is built around revenue per unit or revenue per bed. Get that wrong at the start, and every downstream metric occupancy, NOI, cap rate ends up distorted in ways that aren't obvious until lease-up data starts coming in.

This is worth walking through carefully, because it's less a stylistic modeling choice and more a fundamental difference in what the asset actually is.

Why Revenue Per Unit Breaks Down for Co-Living

Conventional multifamily feasibility models revenue at the unit level because that's the actual transaction one tenant, one lease, one unit. Co-living doesn't work that way. A single unit might have four or five bedrooms, each leased individually to a different tenant, with shared common space factored into the rent structure. Modeling that unit's revenue the way a conventional multifamily model would one blended rent figure per unit collapses information the feasibility study actually needs.

The practical issue: a co-living unit with five beds at 90% occupancy isn't performing the same as a unit with five beds at 100% occupancy, even though a unit-level model might round both to "occupied." Revenue per bed captures that variance. Revenue per unit hides it.

Simplified illustration — not real figures
unit_revenue_model = {
"unit_1": {"beds": 5, "occupied_beds": 4, "rent_per_bed": "market_rate"},
"unit_2": {"beds": 5, "occupied_beds": 5, "rent_per_bed": "market_rate"}
}

A unit-level model might record both as "leased"
A bed-level model correctly shows unit_1 at 80% bed occupancy

Operating Expenses Don't Scale the Same Way

This is where co-living feasibility modeling gets genuinely harder than conventional multifamily. Operating expenses in co-living don't map cleanly to either the unit or the bed they map to the building's shared infrastructure and turnover frequency, both of which behave differently than in conventional rental housing.

Turnover is a good example. Co-living tenants, especially in markets with younger, more mobile renter bases, tend to have shorter average stays than conventional multifamily tenants. Higher turnover means higher unit-turn costs, more frequent cleaning and furnishing refreshes if the unit is furnished (which most co-living product is), and more leasing and marketing spend per bed than a conventional model would assume. A feasibility model that borrows opex assumptions from a standard multifamily comp set will typically understate these costs, sometimes significantly, because the underlying operating pattern is closer to hospitality than conventional residential.

Building the Bed-Level Model Correctly

A defensible co-living feasibility model generally needs three layers that a conventional multifamily model doesn't require in the same form:

Bed-level revenue tracking. Each bed gets modeled with its own occupancy assumption and rent, rolled up to unit and then building level, rather than starting from a blended unit rent and working backward.

Common area cost allocation. Shared kitchens, lounges, coworking space, and amenities need a cost allocation methodology typically per bed rather than per unit since the shared space serves individual tenants, not units as a whole.

Turnover-adjusted opex. Operating expense assumptions need to reflect the higher-turnover, furnished-unit reality of co-living rather than being pulled directly from conventional multifamily benchmarks.

Feasibility platforms built for this need to handle bed-level granularity as a first-class input rather than a workaround. FeasibilityPro.AI's modeling structure, for instance, allows revenue and occupancy assumptions to be built at the bed level and rolled up automatically, which matters because manually reconciling bed-level and unit-level data in a generic spreadsheet template is where a lot of feasibility errors creep in. Other platforms like EstateMaster tend to be more oriented toward conventional multifamily and require more manual adjustment to handle bed-level granularity accurately.

Where This Matters Most in GCC Markets

Co-living and student housing product in GCC markets, Dubai and Riyadh in particular, often serves a tenant base with different stay-length patterns than co-living products in, say, London or New York. A meaningful share of demand comes from young professionals on shorter-term assignments or students in academic-year-length stays, which pushes average turnover even higher than in some Western co-living markets. Feasibility models built without adjusting for this local pattern using, for instance, a US or UK average length-of-stay assumption tend to understate both turnover costs and the marketing spend needed to keep bed occupancy stable through the year.

Market intelligence from JLL and Colliers on co-living and PBSA (purpose-built student accommodation) absorption in these markets is a more reliable benchmark source here than generalized multifamily data, precisely because the tenant behavior patterns are different enough that conventional residential comps don't transfer cleanly.

The Practical Takeaway

The revenue-per-bed versus revenue-per-unit decision isn't a modeling preference; it's a structural requirement for co-living feasibility to produce numbers that hold up against actual operating performance. Teams that try to force a conventional multifamily template onto co-living product, at unit-level granularity, tend to discover the gap during lease-up, when actual bed occupancy and turnover costs don't match what the pro forma assumed.

Curious how others here are handling the common area cost allocation piece specifically per bed evenly, or weighted by unit size and shared amenity access?

Why Master-Developer Feasibility Looks Nothing Like Standalone Sites

Real Estate Hub — Sat, 22 Aug 2026 04:30:00 +0000

Waterfront land deals get pitched with the same enthusiasm regardless of scale, but modeling one as a master-developer play instead of a standalone site is a completely different technical exercise. If you're building or adapting a feasibility workflow for waterfront development, treating it like a bigger version of a single-plot model is where things start to break.

The Core Structural Difference

A standalone site has one owner, one construction timeline, and one exit strategy. A master-developer waterfront scheme typically involves phased land parcelization, multiple sub-developers or JV partners buying serviced plots, and infrastructure that has to be built and financed years before individual buildings generate any revenue.

That structural difference changes almost every input in a feasibility model:

Revenue timing shifts from "units sold at completion" to "land plots sold or leased across multiple phases"
Cost sequencing front-loads heavily into marine works, seawalls, and utility trunk infrastructure before any vertical construction begins
Risk allocation splits between the master developer (infrastructure and land servicing) and sub-developers (vertical construction and unit sales)

Modeling Marine and Coastal Infrastructure Costs

This is usually the biggest blind spot for teams moving from inland to waterfront feasibility work. Marine infrastructure breakwaters, dredging, seawalls, jetties doesn't follow standard construction cost curves, and it's rarely something a generic cost-per-square-meter benchmark can handle.

A workable approach is to separate the model into distinct cost blocks rather than blending everything into a single blended construction rate:

Total Development Cost =
Marine & Coastal Infrastructure

Land Servicing & Utility Trunk Infrastructure
Vertical Construction (by plot/phase)
Soft Costs & Contingency (weighted higher for marine works)

Marine works typically warrant a higher contingency allocation than standard construction because geotechnical and environmental conditions are harder to fully assess pre-construction, and cost overruns in this category are common enough that they shouldn't be treated as edge cases in the model.

Phasing Logic: The Part Most Models Get Wrong

In a standalone project, phasing is mostly about construction sequencing. In a master-developer waterfront scheme, phasing determines cash flow viability for the entire project. Infrastructure costs for later phases often depend on land sale proceeds from earlier phases which means the model needs to handle circular dependency between infrastructure funding and plot sale timing, not just a linear cost-then-revenue sequence.

A simplified phasing dependency might look like:

Phase 1 Infrastructure Cost → funded by Developer Equity + Phase 1 Plot Sales
Phase 2 Infrastructure Cost → funded partly by Phase 1 Plot Sale Proceeds
Phase 3 Infrastructure Cost → contingent on Phase 1 & 2 absorption rates

If Phase 1 absorption is slower than projected, Phase 2 infrastructure funding gets delayed, which pushes the entire remaining timeline. Feasibility models that treat each phase as independent will consistently overstate how quickly a waterfront masterplan can deliver.

Sub-Developer JV Structures Add Another Layer

Master developers frequently sell serviced plots to sub-developers under structures that include design guidelines, delivery obligations, and sometimes revenue-share or buyback clauses if delivery deadlines aren't met. Feasibility modeling for the master developer needs to account for:

Plot sale pricing versus retained land value if plots are held longer for appreciation
Infrastructure cost recovery embedded in plot pricing
Enforcement risk if a sub-developer under-delivers relative to the masterplan's design intent, which can affect the value of adjacent, unsold plots

This last point is easy to underweight. A sub-developer that delivers a lower-quality product than the masterplan promised doesn't just create a problem for their own plot it can measurably affect absorption and pricing for the master developer's remaining inventory.

Tools and Workflow Considerations

Given the multi-entity, multi-phase nature of these deals, teams are increasingly moving away from single-workbook Excel models toward platforms that can handle phase-linked scenario testing more natively. FeasibilityPro.AI has built out modules specifically for phased infrastructure cost recovery and plot-level sensitivity testing, which addresses a real gap most general-purpose feasibility tools are built around single-asset underwriting rather than master-plan-level cash flow modeling. Teams also use EstateMaster or Aprao for the vertical construction feasibility at the sub-developer level, effectively running two connected models: one for the masterplan infrastructure economics, and one for individual plot-level development feasibility.

Practical Takeaways

Waterfront master-developer feasibility isn't a scaled-up version of standalone site modeling it's a different discipline that requires separating marine infrastructure costs from standard construction costs, modeling phasing as a funding dependency rather than a simple timeline, and accounting for the second-order effects of sub-developer performance on the broader masterplan's value.
For anyone building or refining a feasibility workflow in this space: how are you currently handling the circular dependency between phase funding and plot absorption in your models? Genuinely curious what approaches others have landed on.

Data Privacy and AI in Real Estate: What Development Teams Should Ask Their Software Vendors

Real Estate Hub — Sat, 15 Aug 2026 04:30:00 +0000

Real estate development teams have gotten comfortable feeding sensitive information into feasibility platforms: land acquisition prices, JV structures, internal cost projections, sometimes personal financial data from investors in a deal. Now that most of these platforms have layered AI features on top automated assumption suggestions, natural language querying, AI-assisted underwriting narratives the data privacy conversation has gotten more complicated, and a lot of teams haven't caught up to it.

Why This Matters More Than It Used To

A traditional feasibility spreadsheet lives on a local machine or a company server. The data doesn't leave the building unless someone emails it. Cloud-based feasibility software already changed that equation once, and AI features change it again, because now there's a question of where the data goes when a large language model processes it, whether it's used to train anything, and how long it persists somewhere the development team doesn't control.

This isn't a hypothetical concern. Development deals often contain information that's commercially sensitive on its own acquisition pricing before a deal closes, internal margin targets, investor identities, and in some jurisdictions, personal data tied to KYC or investor onboarding falls under formal privacy regulation.

The Core Questions to Ask a Vendor

Where does the data go when an AI feature processes it?

Some platforms route AI features through third-party model providers via API calls. That's not inherently a problem, but the team needs to know: is data sent to an external LLM provider, is it used only for that single request, and is there a contractual guarantee it isn't retained or used for model training? Vendors should be able to answer this specifically, not with a general reassurance.

Is data used to train models that other customers' outputs draw from?

This is the question that gets glossed over most often. A development team doesn't want its acquisition assumptions or cost structures indirectly informing outputs served to a competitor using the same platform. Reputable vendors, including feasibilitypro.ai, structure their AI architecture so customer data isn't pooled into shared training sets but that's a claim worth verifying contractually, not just accepting as a marketing statement.

What's the data residency and retention policy?

For GCC-based teams working with sensitive land and pricing data, or for teams under regulations like GDPR when handling EU-connected investors, data residency matters. Ask where data is physically stored, how long it's retained after a project is closed out, and whether it can be fully deleted on request.

How is access controlled within the AI feature itself?

Traditional role-based access control in a feasibility platform is well understood analysts see what they're assigned to, admins see everything. AI features can complicate this if a natural-language query interface allows a user to ask questions that pull data outside their normal access scope. It's worth confirming that AI query layers respect the same permission boundaries as the rest of the platform, rather than operating with broader access by default.

What happens during a security incident?

Every vendor should have an incident response process, but it's worth asking specifically how AI-related incidents are handled for example, if a prompt injection vulnerability or a model output leak were discovered, what's the disclosure timeline and remediation process.

Architecture Patterns Worth Understanding

Development teams evaluating vendors don't need to become security engineers, but a basic grasp of the architecture helps ask better questions. Platforms generally fall into a few patterns:

Direct API pass-through: user input goes straight to a third-party LLM provider with minimal intermediation. Faster to build, but places more trust in the upstream provider's data handling.
Proxied with data scrubbing: the platform strips or masks sensitive identifiers before sending data to the model, then reinserts context afterward. More engineering overhead, but reduces exposure.
Self-hosted or private model deployment: larger platforms sometimes run models within their own infrastructure or a private cloud instance, avoiding third-party data transmission entirely for certain features.

None of these patterns is universally "correct" the right choice depends on the sensitivity of the specific feature. An AI feature that summarizes public market data from JLL or CBRE reports carries much lower risk than one processing a live acquisition price before a deal is signed.

Practical Advice for Development Teams

Before rolling out an AI-enabled feasibility tool across a team, it's worth running a short internal exercise: map what data categories flow through the platform (public market data, internal assumptions, investor personal data, executed deal terms) and rank them by sensitivity. Then match that against the vendor's actual data flow not their marketing page, their technical documentation or a direct answer from their security team.

Tools like Aprao and EstateMaster have had to answer these questions as they've added AI-assisted features, and the vendors doing this well tend to be transparent about architecture rather than vague. If a vendor can't clearly explain where data goes when an AI feature runs, that's usually a sign the internal architecture hasn't been fully thought through yet either.

How is your team handling this internally are you drafting formal vendor security questionnaires for AI features specifically, or still relying on general data processing agreements that predate the AI rollout?

Feasibility Software Buying Guide: What to Ask Before You Switch From Excel-Only Workflows

Real Estate Hub — Sat, 08 Aug 2026 04:30:00 +0000

Most feasibility teams don't decide to leave Excel because Excel stopped working. They decide because the workbook got big enough that nobody trusts it anymore too many linked tabs, too many hardcoded overrides from a deadline three quarters ago, too much risk in a single broken cell reference. The switch to dedicated feasibility software usually happens under pressure, which is exactly when teams make the worst buying decisions.

This is a practical rundown of what actually matters when evaluating feasibility software, aimed at the technical questions that tend to get skipped in a sales demo.

Why "Replace Excel" Is the Wrong Framing

Almost no feasibility platform on the market fully replaces Excel, and treating that as the goal sets up disappointment. What these platforms actually do is take over the parts of the workflow where Excel is structurally weak: version control, audit trails, scenario management, multi-user collaboration, while leaving room for analysts to still export, adjust, and sanity-check numbers in a spreadsheet when they need to.

The better question isn't "can this fully replace our Excel models." It's "which parts of our current Excel workflow are actually causing risk or wasted time, and does this tool fix those specific problems?"

Questions to Ask About Data Architecture

Before evaluating features, it's worth understanding how a platform actually stores and structures a feasibility model under the hood, because this determines how flexible the tool will be later.

Is the underlying model structure open or proprietary? Some platforms store assumptions in a format that can be exported and audited independently; others lock the logic inside the application, which becomes a problem the day an investment committee wants to see the raw calculation chain.
How does the platform handle formula-level auditability? Feasibility models get scrutinized line by line during due diligence. A tool that can't show its work at that level of granularity creates friction exactly when speed matters most.
Can the platform ingest existing Excel models, or does adoption mean starting from zero? Rebuilding years of historical feasibility models from scratch is a real cost that rarely shows up in the initial pricing conversation.

Integration Questions That Actually Matter

Feasibility work doesn't happen in isolation. The model needs to talk to market data sources, accounting systems, and sometimes GIS or planning data, depending on the market.

Worth asking directly:

Does the platform support API access for pulling in market data feeds comparable sales, rental benchmarks, cost indices from providers like JLL, CBRE, or Colliers, or does that data still need manual entry?
How does the tool handle multi-currency and multi-jurisdiction modeling, particularly for teams working across GCC markets with currency pegs alongside UK or North American deals priced in floating currencies?
Is there a documented API or webhook system for connecting the feasibility model to project cost tracking tools, or does cost data need to be re-entered separately once construction starts?

Platforms like FeasibilityPro.AI have leaned into this integration layer specifically, with connectors built for GCC market data and currency-linked sensitivity modeling, which matters a lot more for teams underwriting Dubai or Riyadh deals than it does for a purely domestic UK developer. Tools like Northspyre lean harder into the cost-tracking and construction monitoring side, so the right fit really depends on where in the development lifecycle the biggest pain point actually sits.

Evaluating Scenario and Sensitivity Modeling Capability

This is where the gap between Excel and dedicated software tends to be widest, and also where teams most often underestimate what they need until they're already mid-deal.

A useful test during any evaluation: try to build the same three-way sensitivity table construction cost escalation, interest rate movement, and absorption timing that would normally take an afternoon of formula wrangling in Excel. If the platform can generate that scenario matrix in minutes and let a Development Director toggle assumptions live during an investment committee meeting, that's a genuine workflow improvement. If it just recreates the same static output Excel already produces, the switching cost probably isn't justified yet.

Platforms like Aprao and Deepblocks have built reputations around exactly this kind of live scenario modeling, particularly for teams running frequent land bid comparisons where speed of iteration matters as much as accuracy.

Questions About Team Workflow, Not Just Software Features

A tool evaluation that only looks at features misses half the picture. Some of the more useful questions are organizational:

Who on the team actually builds models today, and does the new tool require a different skill set or a steeper learning curve than the current Excel-based process?
How does the platform handle permissions and version history when multiple analysts are working on different phases of the same masterplan simultaneously?
What does the migration path look like for models currently mid-deal is there a hybrid period where both systems run in parallel, and how long does that realistically take?

Teams that skip this step often end up with expensive software that only one analyst knows how to use properly, which defeats the purpose of centralizing the workflow in the first place.

The Real Decision Criteria

The switch from Excel-only workflows makes sense when the cost of Excel's weaknesses broken links, no audit trail, slow scenario turnaround, single points of failure starts outweighing the cost and disruption of adopting new software. That threshold looks different for a two-person boutique consultancy than it does for a development team running a dozen live masterplans across three markets.

The honest answer for most teams is a hybrid approach: dedicated feasibility software for the core model, scenario management, and audit trail, with Excel still in the loop for quick ad hoc checks and one-off client requests. Trying to eliminate Excel is usually more disruptive than it's worth.

What's actually driving your team's evaluation right now is it the audit trail problem, the scenario speed problem, or something else entirely? Curious what's tipping the decision for other feasibility teams.

VAT and Transaction Taxes: The Line Items Feasibility Analysts Often Underestimate

Real Estate Hub — Sat, 01 Aug 2026 10:25:44 +0000

Run enough feasibility models, and you'll notice a pattern: the assumptions that get the most scrutiny are the ones everyone already understands. Construction cost per square meter. Sales absorption. Exit yield. Meanwhile, VAT and transaction taxes sit quietly in a corner of the model, often modeled as a rounding exercise rather than a real cost driver.

That's a mistake we see repeated across markets, and it tends to surface at the worst possible time after land has been acquired and the capital stack is already committed.

Why VAT Gets Modeled Incorrectly

VAT treatment in real estate isn't uniform. Whether it's recoverable, irrecoverable, or partially blocked depends on the asset class, the jurisdiction, and sometimes the specific use of the space within a single building.

A residential-for-sale component might sit outside the VAT net in one market, while the retail podium beneath it is fully taxable. Mixed-use schemes are where this gets genuinely difficult, because a single feasibility model often needs to split VAT treatment by floor, by unit type, or by tenant category and analysts don't always build that granularity in from the start.

The common shortcut is applying a single blended VAT assumption across the whole scheme. It's faster to model, but it tends to understate the cost on the taxable components and overstate it on the exempt ones, which distorts the return profile of each asset class rather than just the project as a whole.

Transaction Taxes Are a Cash Flow Issue, Not Just a Cost Line

Transfer taxes, registration fees, and stamp duty get treated as a one-time deduction in a lot of models. In practice, they behave more like a cash flow event than a static cost they hit at specific points (land acquisition, unit transfer, refinancing) and the timing matters as much as the amount.

In a phased development, transaction taxes can recur at each disposal event rather than once at project completion. If a model only captures the tax at financial close and ignores subsequent triggers, the feasibility output looks stronger than the actual project economics will support.

Cross-border structures add another layer. When capital flows through holding entities, SPVs, or joint venture structures, transaction taxes can apply at more than one point in the ownership chain. We've seen models that account for the tax on the underlying asset transfer but miss the tax triggered by a change in beneficial ownership at the holding company level.

Where This Shows Up in Practice

Development Directors reviewing feasibility outputs often catch this late, usually during due diligence, when a tax advisor flags an assumption that doesn't match the structure being proposed. At that point, the model needs rework, and depending on how tight the timeline is, that can mean renegotiating terms that were already agreed.

Feasibility Analysts building the model from the ground up have more room to get ahead of it: pulling in tax input at the assumptions stage rather than the sensitivity stage, and treating VAT recoverability as a variable that changes by asset class rather than a constant.

Tools like EstateMaster and Aprao allow VAT and transaction tax inputs to be broken out by cost category, which helps, but the structuring logic still has to come from the analyst. Platforms like FeasibilityPro.AI are built around letting that logic sit alongside the underlying Excel workflow, so the tax treatment doesn't get lost when assumptions change mid-model.

What This Means for Feasibility Work Going Forward

The projects that get this right tend to involve tax advisory input earlier, often before the model's first draft rather than after. It's a small shift in process, but it changes how much rework happens later.

If you're building or reviewing feasibility models regularly: how granular does your VAT treatment go by asset class, and at what stage does tax input typically enter your process? Curious how this is handled across different markets.