← All Learn posts
What Goes in a Real Estate Development Financial Model

What Goes in a Real Estate Development Financial Model

Rashdan·14 Sep 2026·4 min readGuideArticle

Direct answer: A real estate development financial model is a period-by-period projection of a project's costs, revenues and financing, converting assumptions into cashflows, an equity waterfall and return metrics such as IRR, NPV, DSCR and peak equity. A credible model is built in layers — assumptions, calculations, outputs — so any change flows through automatically and every number traces back to its source.

Committees don't reject deals because the returns are modest. They reject them because the model can't explain itself. Structure is credibility.

1. Layered architecture: assumptions, calculations, outputs

Inputs live in one place, clearly flagged. Calculations reference them — never hardcode a number inside a formula. Outputs pull from calculations only. This single discipline is what separates a model that survives review from one that collapses when a lender asks "what if land costs move 8%?"

2. The cost stack, timed properly

Land, hard costs, soft costs, financing costs, contingencies — each escalated and spread across the programme on a construction S-curve. Timing matters as much as totals: spend in month 6 and spend in month 18 carry very different interest. Forgetting escalation or front-loading the S-curve are the two quiet killers of cost realism.

3. The revenue side: sale versus hold logic

For-sale projects: unit mix, pricing, absorption pace — and crucially, when cash actually arrives. The payment regime decides this: Dubai's escrow law releases buyer payments only at certified milestones; Australia's 10/90 defers 90% of inflows to completion; other markets run custom splits, staged retentions or no escrow at all. Hold projects: rent ramps, vacancy, operating expenses, and an exit value derived from a defensible cap rate. Mixing sale and hold logic in one undifferentiated revenue line is how models lie.

4. Financing and the waterfall

Sources and uses; construction debt drawn against progress with interest carry on the outstanding balance; equity calls timed to the gap. Then the distribution waterfall in contractual order: senior debt service, return of capital, preferred returns, promote splits. Peak equity — the maximum cash the sponsor must fund — belongs on the first page, because it's the number that decides whether the deal is financeable at all.

5. The outputs a committee actually reads

Development IRR and equity multiple (speed and scale), NPV, DSCR and interest cover for the lender's view, loan-to-cost, and a sensitivity table or tornado chart showing which variables break the deal first. If your dashboard can't answer "what hurts most?" in one glance, it isn't finished.

6. Scenarios as switches, not copies

Base, upside and downside should be one model with assumption switches — never three copied files. Copies drift; switches stay honest. A downside case built by duplicating "final_v7" is not a scenario, it's an alibi.

Where most models break

Hardcodes buried in formulas. Circular references handled by hope rather than deliberate iteration (construction interest on drawn debt is inherently circular — design for it). Monthly construction detail mixed with quarterly operating detail without reconciliation. No error checks, no traceability, and no payment-structure logic in the inflow timing.

The workflow today

Building this architecture by hand is weeks of disciplined work; maintaining it across scenarios is weeks more. Modern AI-assisted engines assemble the layered structure, payment-structure timing and scenario switches automatically, and recalculate the whole chain when an assumption moves — leaving the modeller to defend the assumptions rather than repair the links.

Key takeaways: Layers: assumptions → calculations → outputs · Time the cost stack on a real S-curve · Sale and hold revenue logic are different animals · Peak equity decides financeability · Scenarios as switches, never copies · Traceability is credibility.

A development model is an argument about the future, expressed in numbers. Build it so every number can defend itself.

Try FeasiBuild free

Related reading