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 gap is now obvious from inside the workflow. A standard tool for feasibility that respects the analytical depth, replaces the file with a queryable system, captures assumption metadata, and produces audit-ready outputs would, on adoption, materially improve capital allocation across the asset class. The fact that no such standard has emerged is not because the problem is unworthy. It is because the founders of previous attempts solved the wrong layer. The next standard will not look like Excel and will not look like the previous generation of feasibility software either. It will look like a system whose unit of work is a query, not a file, and whose memory is institutional, not artisanal. That is the category that 2026 and 2027 are quietly setting up.
Related Reading
- why most PropTech fails at the architecture level
- what the next generation of feasibility software looks like
- the operator’s case for AI-first feasibility
- the new cost of building software
Key Takeaway
The real estate feasibility Excel problem is not that Excel is a bad tool. It is that Excel is now a structural liability at the scale GCC developers operate. Version control, error propagation, and scenario fatigue compound into underwriting risk that boards no longer want to carry.
Frequently Asked Questions
What is the Excel problem in real estate feasibility?
It is the structural set of risks created when complex, multi-billion-riyal underwriting decisions sit inside spreadsheets: untracked version control, formula errors, broken links, and analyst dependency. The model is fragile by design.
What error rate is typical in Excel-based feasibility?
Independent research on enterprise spreadsheets consistently puts material error rates above 80% of files. In real estate feasibility, where models run thousands of dependent cells across multiple scenarios, the practical error rate is higher still.
What replaces Excel for GCC developer feasibility workflows?
Replacement is not a single tool. It is a workflow shift toward purpose-built feasibility platforms with scenario versioning, audit trails, and AI-assisted analysis. The replacement is now economically viable in a way it was not three years ago.
Naumaan Khan is a Digital Growth and Transformation consultant in Muscat, Oman. He builds AI-native growth systems for enterprise organisations across the GCC.