You're looking at a site, and the seller's price doesn't make sense against your numbers. After some digging, the reason turns up: the ask is based on a bigger scheme than the one the planning position supports. Maybe it assumes more floor area, a different use mix, or a density that's only been discussed informally.
Stress-testing a site against a different development scheme is a modeling problem as much as a negotiating one. If your feasibility model hard-codes one scheme, you can't compare the seller's version to yours without rebuilding it. This post covers how to structure the model so you can, with a small Python sketch of the core logic.
Why Scheme-Driven Feasibility Modeling Needs Parameterization
A development scheme is a bundle of inputs: gross floor area (GFA), efficiency ratio, unit mix, height, parking, sales or rental rates, and build cost per square meter. Change the scheme, and most of those move together. Higher density usually raises GFA but also changes efficiency, cost per square meter, and sometimes achievable pricing, since a taller or denser building may not sell at the same rate per square foot.
If these live as scattered values across a spreadsheet, changing scheme means hunting through cells and hoping nothing is missed. The cleaner approach is to isolate scheme parameters in one block, drive revenue and cost lines from it, and keep market and financial assumptions separate. Then "seller's scheme" and "permitted scheme" are just two parameter sets feeding the same engine.
A Minimal Residual Land Value Engine for Comparing Schemes
The sketch below uses hypothetical numbers (AED millions, areas in square meters) and a deliberately simplified structure. It's illustrative, not a production model.
from dataclasses import dataclass
@dataclass
class Scheme:
name: str
plot_area: float # sqm
far: float # floor area ratio
efficiency: float # net saleable / gross
price_per_sqm: float # AED per net sqm
build_cost_sqm: float # AED per gross sqm
soft_cost_pct: float # of build cost
def residual_land(s, profit_pct=0.20, finance_pct=0.05, acq_cost_pct=0.05):
gfa = s.plot_area * s.far
nsa = gfa * s.efficiency
gdv = nsa * s.price_per_sqm / 1e6
build = gfa * s.build_cost_sqm / 1e6
soft = build * s.soft_cost_pct
finance = (build + soft) * finance_pct
profit = gdv * profit_pct
residual = gdv - build - soft - finance - profit
return residual / (1 + acq_cost_pct) # max land price
permitted = Scheme("Permitted", 10_000, 3.0, 0.80, 14_000, 5_500, 0.15)
sellers = Scheme("Seller's", 10_000, 4.5, 0.78, 14_000, 5_700, 0.15)
The finance line here is a flat percentage of cost, which is a placeholder. A real model would calculate interest on the actual drawdown schedule, which also introduces the circularity between land price and finance cost mentioned in most residual land value discussions.
Running both gives:
for s in (permitted, sellers):
print(s.name, round(residual_land(s), 1))
With these hypothetical inputs, the permitted scheme supports a maximum land price of roughly 66, and the seller's higher-density scheme supports roughly 79. If the seller is asking somewhere near the second figure, the price is only defensible if the denser scheme is achievable. That's the question to put to the seller, and to your planning adviser.
Stress-Testing the Seller's Scheme, Not Just Your Own
Once both schemes sit in the same engine, the useful step is to test the seller's assumptions individually rather than rejecting the price outright. Hold the seller's scheme and change one thing at a time. What if the FAR is 3.8 instead of 4.5? What if efficiency drops because the extra height needs larger cores? What if achievable pricing is lower because the product is denser?
The seller's scheme also changes the cost side. Taller buildings generally have a higher cost per square meter, longer programs and different structural requirements. Models that increase GFA while holding build cost per square meter flat overstate the benefit of density, and that's one of the most common errors when comparing schemes.
Next, run a grid: FAR on one axis, price per square meter on the other, maximum land price in each cell. This shows how much of the seller's price depends on each assumption, and where the break-even sits.
Weighting Scenarios When Planning Outcomes Are Uncertain
Whether the denser scheme is approvable is a probability question, and the model doesn't answer it. What the model can do is show the price at which you'd be comfortable under different planning outcomes. One practical approach is to price the site off the permitted scheme and treat any additional density as upside the seller has to share, for example through a deferred payment, an overage clause or a planning-linked price adjustment.
If you do assign probabilities, label them clearly as judgment. Don't let them slip in as if they were data. A probability-weighted land value built on an unexamined 60% planning success rate can look more rigorous than it is.
Making the Comparison Auditable
When two schemes are compared, reviewers will want to see exactly what differs. Keep the parameter block compact, version it, and have the model output a side-by-side table of every parameter that differs between schemes, along with the resulting land value. If a calculation sits in Excel, ensure each scheme's inputs can be traced to a cell range and the output can be reproduced from them.
Teams building or buying this kind of tooling may weigh platforms such as Feasibilitypro.AI, EstateMaster, Deepblocks, Northspyre and Aprao, with the relevant comparison depending on asset classes, market data, scenario analysis, Excel integration, collaboration and auditability. In-house Python or Excel builds are equally common. Either way, the property that matters is reproducibility: another analyst should get the same land value from the same inputs.
Limitations of Comparing Development Schemes in a Model
This approach is a simplification. Real schemes differ in unit mix, phasing, amenity requirements and infrastructure contributions, none of which a single FAR and efficiency pair captures. The finance treatment in the sketch is crude. Pricing assumptions are the most fragile input and need evidence from recent achieved transactions rather than asking prices. And the output is a sensitivity, not a forecast. A model can show what the site is worth under a scheme; it can't tell you whether that scheme will be approved.
Practical Takeaways for Stress-Testing a Site
Isolate scheme parameters so any scheme can be run through the same engine. Compare the seller's scheme and the permitted scheme side by side, and test the seller's assumptions one at a time. Flex build cost with density rather than holding it flat. Present maximum land price as a grid, not a point. And keep a record of which assumptions are evidence and which are judgment.
Top comments (0)