Real Estate - Noumaan Khan

The Excel Problem in Real Estate Feasibility

Leave a Comment / Real Estate / Naumaan Khan

A multi-billion-dirham asset class is still being underwritten in spreadsheet files emailed between analysts, and the cost is not inefficiency, it is bad capital allocation at scale. Real estate feasibility in the GCC is a category that produces some of the most consequential capital decisions in the region, on a workflow that has not materially evolved since the late 1990s. An analyst opens an Excel template inherited from a previous project. They modify cells. They email the file to the development director. The director changes assumptions. The file is renamed v2. The analyst re-runs scenarios. v3, v4, v5. Six weeks later a deal goes to investment committee on a file whose audit trail is a chain of Outlook timestamps. Multiply this by every project in every developer in every market in this region and the macro picture is that hundreds of billions of dirhams of capital allocation is being decided on a workflow that would not be acceptable in any other industry handling comparable sums. How feasibility is actually done today The realistic workflow inside most GCC developers and consultancies is some variant of the following. A senior analyst owns the master template. The template was built over years, refined by accumulated experience, and is deeply customised to the firm’s logic. New project starts. The template is duplicated. Inputs are populated: location, plot ratio, expected unit mix, build cost assumptions, sales velocity assumptions, finance terms, exit cap rate. Outputs are calculated: NPV, IRR, equity multiple, sensitivity tables. The file then enters revision. Every senior stakeholder has views on the assumptions. The director thinks the build cost is conservative. The CFO thinks the sales velocity is optimistic. The investor representative wants a more aggressive exit assumption tested. Each round of feedback produces a new file. By the time the deal goes to committee, there are typically eight to fifteen versions of the file, with no single source of truth and no canonical record of which assumptions were challenged, by whom, and how the team responded. This is not a strawman. This is the workflow inside firms running tens of billions of dirhams of GLA. The reason it persists is not that the people are unsophisticated. They are highly sophisticated. The reason it persists is that the category has not produced a standard better than Excel that respects the actual analytical complexity these professionals require. The specific failure modes of Excel Excel survives because it is flexible. Every other property of Excel as a feasibility tool is a failure mode at enterprise scale. Version entropy. The proliferation of file versions is not a discipline problem. It is a structural property of file-based collaboration. Even with rigorous naming conventions, the canonical version drifts and the audit trail becomes fragile within hours of the first revision. Unauditable assumptions. An assumption in cell K47 has no metadata. There is no field that records who set the value, when, against what evidence, with what challenge from whom. The cell holds a number. The story behind the number lives in the analyst’s head and in the email chain. When the analyst leaves the firm, the story leaves with them. Static sensitivity. The standard sensitivity table in a feasibility model varies one or two assumptions at a time against a fixed structure. Real sensitivity in the GCC market involves many correlated variables (unit mix, payment plan, sales velocity, financing structure, exit timing) interacting in ways a static table cannot represent. The output is presented as definitive when it is one slice of a multidimensional surface. Brittleness on integration. Connecting a feasibility model to live cost data, live market comparables, or live financing terms is artisanal work. Every connection is a custom build. Every custom build breaks when the source format changes. Most firms do not attempt the integration, which means the feasibility runs on data that is two months old at best. Reproducibility failure. Asked to reproduce a feasibility result from 18 months ago, exactly as it was presented to investment committee, most firms cannot. The file exists. The state of the file at the moment of decision does not. This is not a record-keeping problem. It is an architecture problem. The unit of work is a file, and files do not preserve state. Quantifying the cost The temptation is to describe these failure modes in time terms: “the team spends three weeks on a feasibility that should take three days”. The time cost is real but it is not the largest cost. The largest cost is decision risk. A capital deployment decision made on a feasibility whose assumptions cannot be audited and whose sensitivity is one-dimensional is a riskier decision than the same deployment made on an auditable, multidimensional model. The risk premium is invisible until a project underperforms, at which point the post-mortem typically discovers that the original feasibility had assumed something the team would not have signed off on if they had seen it isolated. The institutional answer is “we will be more careful next time”. The structural answer is that the toolset cannot surface the assumption to the place where it would be challenged. In a portfolio of, for example, ten projects per year at average GDV of 200 million dirhams, the difference between a 70% and an 85% confidence-correct feasibility process is meaningful capital. This is the actual cost. Not the analyst hours. The capital allocation quality. Why Excel survived this long Three reasons. First, the analytical sophistication required is genuinely high, and most attempts to replace Excel produced tools that were less flexible, less powerful, or less customisable for the specific market logic. Second, the senior people who run these workflows learned them in Excel and have built career-defining intellectual capital in their templates. The switching cost is personal as well as organisational. Third, the previous generation of “feasibility software” attacked the problem at the wrong layer, replacing the file with another file, just inside a different vendor’s UI. The architectural problem was untouched. The category gap this creates The category

The Excel Problem in Real Estate Feasibility Read More »

What AI Changes About Real Estate Underwriting

Leave a Comment / Real Estate / Naumaan Khan

Faster spreadsheets is the boring answer. The real shift is that defensible assumptions become a queryable asset rather than a buried footnote, and that changes how capital gets deployed. The narrative that “AI will speed up real estate underwriting” is technically true and strategically uninteresting. Speed in itself is a productivity gain, not a paradigm shift. The actual shift AI introduces to underwriting is structural. The objects underwriters work with stop being numbers in cells and start being defensibility arguments with metadata. Capital allocation, downstream, gets made on a different quality of evidence. That is the real story, and it is not the story being told in most vendor pitches. The three fundamental changes AI changes three things about underwriting at the architectural level. Each change has compounding implications. First, persistent assumption context. In a pre-AI workflow, an assumption sits as a value in a cell. The reasoning behind the value lives in the analyst’s notes, the email thread, the analyst’s memory. In an AI-native workflow, the assumption is an object. It carries metadata: source of evidence, comparable transactions, challenges raised in review, resolutions, sensitivity to other assumptions, last updated date and rationale. The model maintains this context across sessions, across analysts, across projects. The institutional knowledge of why a 6.5% cap rate is appropriate for this submarket in 2026 stops being something the senior analyst carries in their head and becomes a queryable artefact. Second, scenario velocity. Pre-AI sensitivity analysis is one or two variables flexed against a static structure. The analyst pre-computes a small number of scenarios because each scenario takes time. AI-native sensitivity is fundamentally different. The model can run hundreds of correlated scenarios in seconds, surface the ones where the project economics break, and explain why. The decision-maker is no longer choosing between three scenarios the analyst pre-computed. They are interrogating the entire scenario space. Third, audit-ready outputs. Pre-AI, a board-ready feasibility deck is constructed manually after the analytical work is done. The link between the deck and the underlying calculations is artisanal, often broken in revisions, and rarely fully reproducible 18 months later. AI-native outputs are produced from the same queryable system that holds the assumptions. The board pack regenerates from the source, every time, with full traceability. The standard of defensibility rises by an order of magnitude. What each change means for underwriters For the analyst doing the underwriting, persistent assumption context means the cognitive load drops sharply. They are no longer holding the rationale for fifty assumptions in their head. The system holds it. They are doing the work of judgement and challenge, not the work of memory. The output of a senior analyst becomes higher quality and they can run more deals concurrently without quality loss. Scenario velocity means the analyst can answer questions in real time that previously required overnight reruns. Investment committee asks “what if the sales velocity is 20% slower from month nine”? The analyst pulls the scenario in front of the committee, in the meeting, with full sensitivity. The dynamic of the meeting changes. The committee challenges become richer because the analytical capacity to respond has expanded. Audit-ready outputs mean the analyst’s reputation is no longer constructed on whether the deck looked tight. It is constructed on whether the underlying analysis was rigorous, because the deck is now derivative of the analysis. This rewards substance over presentation, which is structurally what the analyst has wanted for a decade. What it means for development directors For the development director, the shift is in approval discipline. Pre-AI, the director’s challenge in a feasibility review is bounded by what the analyst pre-computed and what the director can hold in their head from comparables. AI-native lets the director interrogate any combination of assumptions instantly. The challenge becomes structural, not selective. The bad assumptions that used to slip through because nobody asked the right specific question now get caught because the marginal cost of asking another question is zero. The director’s role shifts from gatekeeper to interrogator. The role is harder, more useful, and produces better capital decisions. What it means for CFOs For the CFO, the shift is the most consequential. CFOs in GCC developers live with a particular anxiety: the feasibility presented to investment committee may not survive contact with construction. Cost overruns, sales velocity disappointments, exit cap movements all reveal, in retrospect, that the original feasibility had assumed something less defensible than the deck implied. AI-native underwriting changes the CFO’s posture. The defensibility of every assumption is queryable, not implicit. Post-mortem on a project that underperformed becomes an analytical exercise that surfaces specific assumptions that did not hold and links them to the institutional logic of the firm. The next project’s feasibility benefits from the post-mortem of the last one in a structured way, not in a “we will be more careful” way. CFO confidence in the feasibility process rises, which structurally increases the pace and ambition of capital deployment. The capital allocation implication Step back from individual roles and the macro implication is large. A developer running AI-native underwriting allocates capital with measurably higher confidence than a peer running file-based underwriting. Higher confidence means more aggressive but defensible deployment. Faster cycle times. Better risk-adjusted returns over a portfolio of projects. The competitive gap between AI-native developers and file-based developers, in a market like the GCC where capital is plentiful and discipline is the constraint, will be material by 2028. This is not a productivity story. It is a market structure story. The developers who adopt AI-native underwriting in 2026 will, three years later, be running portfolios with measurably better risk-adjusted returns than peers, and the capital flowing into the region will price that difference. By the time the laggard developers notice, the cost of catching up will involve replacing tools, retraining teams, and rebuilding institutional context, which is a multi-year investment they will keep deferring. Why “AI-enhanced Excel” misses the point The current vendor pitch in this category is heavy on “AI-enhanced Excel” or “AI plug-ins for feasibility

What AI Changes About Real Estate Underwriting Read More »

The Operator’s Case for AI-First Feasibility

Leave a Comment / Real Estate / Naumaan Khan

Forget the founder pitch. Here is what an underwriter, a development director, and a CFO each get out of an AI-first feasibility stack, in their own language. Most conversations about new software in real estate are organised around the founder’s narrative. The platform does this, the platform does that, the platform represents the future. This is the wrong frame for the people who actually decide whether the platform gets adopted. The decision-makers inside a developer have specific roles, specific accountabilities, and specific languages. The case for an AI-first feasibility stack lands when it is made in those three languages, separately and honestly. Below is what that sounds like. The underwriter I spend the bulk of my week running scenarios. Most of that time is not analytical, it is mechanical. Updating cells, copying tabs, re-running sensitivity tables, fixing broken links between models, formatting decks for the director’s review, then re-doing it after the director’s challenges, then re-doing it again after the CFO’s challenges. By the time the file goes to investment committee, I have personally handled forty versions of it and I cannot, with confidence, tell you exactly what changed between version twelve and version twenty. What I get from an AI-first feasibility stack is the return of my analytical hours. The system holds the assumption metadata. When I change a cap rate, the dependencies update and the audit trail records why I changed it. When the director challenges a build cost, I do not rebuild a tab; I update an assumption object, the system regenerates the affected views, and the conversation moves forward inside the same hour rather than the same week. My weekly capacity for genuine analytical work, the kind that requires judgement, comparable selection, market interpretation, doubles. The work that bored me out of the role becomes the work the system does, and the work I came into the role for becomes most of my week. I also get reputation safety. When something goes wrong on a project two years later and the post-mortem traces back to the feasibility, I can show the assumption, the evidence I had, the challenges raised, and the resolution. The system protects the integrity of my work in a way the file never did. The development director I am responsible for ten projects across three submarkets. My job is to make sure each project’s feasibility holds up under scrutiny, that the assumptions are defensible, and that capital is being deployed against an analysis the firm will not regret. The constraint on my judgement is not analytical skill. It is bandwidth. I cannot personally interrogate every assumption on every project at the depth I would like to. I sample. I trust the senior analysts. I rely on the review process. The bad assumptions that slip through tend to be the ones nobody had time to challenge specifically. What I get from an AI-first feasibility stack is the ability to interrogate at depth without paying the time cost. I sit with the analyst, I ask “what happens to project IRR if the leasing absorption assumption is 70% of the analyst case”, and the answer is in front of us in seconds, fully sensitised. I can ask the next question, and the next, until I am satisfied. The marginal cost of an additional challenge is near zero, so I ask the challenges I would not have asked otherwise. The depth of my review on every project rises to a level that the file-based workflow simply did not allow. I also get cross-project visibility. I can ask the system how a given assumption pattern in this project compares to the same pattern across the other nine projects in the portfolio. I can identify outliers in our institutional logic that previously hid inside individual files. The portfolio gets managed as a portfolio rather than as ten separate files. The CFO I sign off on capital deployments that move significant balance-sheet positions for the firm. Every signature carries a specific institutional risk: that the feasibility I approved was less rigorous than it appeared, and that I will be answering for the gap two years from now in front of the board, the auditors, or the shareholders. This risk is not theoretical. I have lived through it. The post-mortem on a underperforming project always reveals that something in the feasibility was less defensible than the deck implied. What I get from an AI-first feasibility stack is auditability. Every assumption I sign off on carries its evidence with it. The system can reproduce the exact state of the analysis at the moment of my approval. If someone asks me, in 2029, why I approved a project on a 4.5% net yield assumption, I can show them not the file but the system state, including the comparables I was shown, the challenges that were raised, and the resolution. My signature stops being a leap of faith and starts being a documented decision against documented evidence. I also get cycle-time benefit. The current cycle of “feasibility prepared, reviewed, revised, presented, revised, approved” takes weeks per project. Compressed cycle times mean we can deploy capital faster against opportunities that have time-sensitive entry points, which in this region is most of them. The function of finance moves from gatekeeper to enabler without lowering the standard of rigour. The organisational case Each role independently has a strong individual case. The organisational case is what happens when all three are using the same system, on the same project, simultaneously. The underwriter, the director, and the CFO are looking at the same artefact. Their challenges, comments, and approvals live in the system, not in email. The institutional context of why this specific cap rate, this specific velocity assumption, this specific build cost contingency, is documented, queryable, and inherited by the next project. The firm is no longer relying on the individual memory of senior people. The firm is building institutional memory that compounds. This is not a productivity story. It is a capability story. The firm’s analytical

The Operator’s Case for AI-First Feasibility Read More »