Your feasibility shows an 18% margin on cost. A Monte Carlo simulation takes that same deal, lets construction cost, sale price and timing each move within a realistic range, recalculates the feasibility thousands of times, and tells you something the single figure never could: that the deal clears your 20% hurdle only about one run in four, and loses money about one run in ten. The base case did not lie. It just showed you one outcome out of thousands, and probably not the most likely one.
That gap is what this guide is about. A property developer works out whether a deal stacks up, and the honest answer is rarely a single number. Costs run over, sales soften, settlements slip, and interest accrues the whole time. Monte Carlo simulation is the technique that turns those uncertainties into a probability: not “the profit is $1,300,000” but “there is roughly a 22% chance of beating 20% on cost, and roughly a 10% chance of a loss.” This guide covers what the method is, why a base case and even a sensitivity table understate risk, how a simulation runs step by step, which feasibility inputs to make variable and the ranges to use, how to choose a distribution, the correlation mistake that quietly breaks most models, how to read the output, a worked example on a small townhouse project, when Monte Carlo is worth the effort against simpler tools, and how the picture shifts across the states and in New Zealand. Every figure here is illustrative and hedged, because the ranges that matter are the ones specific to your site, your builder and your market.
This guide assumes you already build a feasibility. If the cashflow itself is new to you, start with the month-by-month development cashflow model, because Monte Carlo runs on top of that model rather than replacing it.
What Monte Carlo simulation means for a development feasibility
Monte Carlo simulation is a way to model the range of outcomes a deal could produce by running the feasibility thousands of times, each time drawing a slightly different value for every uncertain input. Instead of one construction cost, you give the model a range. Instead of one sale price, a range. The computer picks a random value from inside each range, recalculates the whole feasibility, records the profit and margin, and repeats. After several thousand runs you have not one answer but a distribution of answers, and from that distribution you can read the probability of any result you care about.
The name comes from the Monte Carlo casino, because the method relies on repeated random sampling. IBM describes it as a computational technique that uses repeated random sampling to obtain the likelihood of a range of results occurring, and Investopedia frames it as a way to model the probability of different outcomes in a process that cannot easily be predicted because of the intervention of random variables. The technique is old and general. It is used in physics, engineering, portfolio management and project scheduling. Applied to a development feasibility, the “process that cannot easily be predicted” is your deal, and the “random variables” are the cost, price and timing assumptions you were never really certain about in the first place.
The useful way to picture it for a developer: your feasibility spreadsheet is a machine that turns inputs into a profit. Normally you feed it your single best guess for each input and it returns a single profit. Monte Carlo feeds it thousands of plausible combinations and returns thousands of profits, so you see more than what the deal makes when everything lands on your estimate. You see how often it makes money, how often it beats your hurdle, and how bad the bad cases get. It turns a point estimate into a probability, which is closer to how a development actually behaves.
Why your base case (and even a sensitivity table) understates the risk
A base case tells you what happens if every assumption lands exactly on your estimate, and that almost never happens, so on its own it is close to the least useful summary of a risky deal. The profit figure at the front of a feasibility is a single point drawn from a wide cloud of possible outcomes. It carries no information about how wide that cloud is, whether it leans to the downside, or how likely you are to actually land near the number. Two deals can show the same 18% base-case margin while one is nearly certain to land between 15% and 21% and the other swings from a 5% loss to a 35% windfall. The base case cannot tell them apart. The risk can.
Sensitivity analysis is the usual next step, and it is a real improvement, but it still leaves a gap. A sensitivity analysis flexes one or two assumptions at a time, so you can see that a 5% lift in construction cost cuts your margin by a few points, or read a grid of profit outcomes across a range of cost and price movements. That is genuinely useful for finding which levers matter most. What it does not do is tell you how likely any of those cells are. A sensitivity table shows that a 10% cost blowout combined with a 10% price fall wipes out your profit, but it says nothing about whether that corner of the grid has a 1% chance or a 20% chance of occurring. It also usually moves inputs in isolation or in tidy paired steps, when real projects move many inputs at once and in messy combinations.
Scenario analysis, the third common tool, hand-builds a few named futures: a best case, a base case, a downside, maybe a “perfect storm”. This is easy to explain to a funding partner and it forces you to think about how bad things could get. Its weakness is the same one: you are choosing three or four scenarios out of an infinite number, weighting them by gut feel, and hoping the ones you picked are representative. The gap between deterministic feasibility practice and probabilistic methods is well documented in the property research literature, which repeatedly finds that developers lean on single-point and scenario appraisals while the underlying risk is probabilistic. Monte Carlo does not replace sensitivity and scenario work. It sits above them, taking the ranges you would have used for a sensitivity table and running not nine cells or four scenarios but thousands of combinations, then attaching a probability to each outcome.
There is a subtler reason the base case tends to mislead, and it is the single most important idea in this guide. Development risks are usually asymmetric. Construction cost has more room to run over than to come in under. Sale prices in a soft market can fall further than they rise in a strong one, at least on the timeframe of a single project. Settlements slip more often than they accelerate. When the downside on your key inputs is fatter than the upside, the most likely outcome sits below your base case, not on it. A Monte Carlo simulation surfaces that gap directly. It is common to run a deal and find the median simulated margin two or three points below the base case, purely because the risks lean down. If you only ever look at the base case, you are quietly building in an optimism you never chose.
How a Monte Carlo simulation actually runs, step by step
A Monte Carlo simulation on a feasibility is five repeated steps, and understanding the loop is most of understanding the method. The sequence below is what happens on every single iteration, and a full run is just this loop repeated thousands of times.
First, you define each uncertain input as a range with a shape, not a single number. Construction cost stops being “$4,200,000” and becomes “most likely $4,200,000, as low as $4,070,000, as high as $4,700,000, skewed towards overrun”. You do this for every input you think carries real uncertainty, and leave the rest as fixed values.
Second, the model draws one random value from inside each range. On this iteration it might pull a construction cost of $4,380,000, a sale price 3% below your estimate, a sell-down two months slower than planned, and a debt rate of 9.1%. The draws respect the shape you set, so values near the most likely figure come up more often than values out at the extremes.
Third, the model recalculates the entire feasibility using that particular set of drawn values. Every downstream number reprices: the total development cost, the interest bill (which depends on both the cost base and the timing), the net revenue, and finally the profit and the margin. This is why the simulation has to run on a real feasibility model and not just a profit formula, because timing feeds interest, interest feeds cost, and cost feeds the margin.
Fourth, the model records the results of that iteration: the profit, the margin on cost, the margin on revenue, and any other metric you are tracking, such as the Internal Rate of Return (IRR) or peak funding.
Fifth, it throws those particular draws away and repeats from the second step with a fresh random set. Do this 5,000 or 10,000 times and you accumulate a large sample of possible outcomes for the same deal. Sort that sample and you can read the median, the spread, the probability of clearing your hurdle, and the probability of a loss. Microsoft’s own guidance on running Monte Carlo simulations in Excel describes exactly this pattern of repeated recalculation to model the impact of risk and uncertainty in a forecasting model, and MathWorks frames it as studying how a model responds to random inputs.
How many iterations is enough? Generally, a few thousand is plenty for a development feasibility, and running more mostly buys smoother-looking output rather than better decisions. A practical habit is to run the simulation twice with different random seeds and check that the headline probabilities, the chance of hitting your hurdle and the chance of a loss, barely move between runs. If they jump around, add iterations. If they are stable, you have enough.
Which feasibility inputs to make variable, and the ranges to use
Make an input variable when its uncertainty is large enough to move the margin and when you cannot pin it down at the time you are running the feasibility. For most Australian developments that shortlist is short, and loading up the model with twenty jittering inputs tends to hide the few that actually drive the result. The inputs below are the ones that generally earn a range.
Construction cost is usually the largest single cost and one of the most uncertain, so it is the first input most developers make variable. Ground the range in current data rather than a round number. Rider Levett Bucknall forecasts national construction cost escalation of 4% to 6% for 2026, and its market updates note that labour shortages remain the sector’s most persistent constraint while construction activity has pushed to record levels that keep cost pressure elevated. That escalation is only the baseline drift. On top of it sits project-specific overrun risk from variations, latent site conditions and programme slippage. A common way to set the range is to put the most likely value at your quantity surveyor’s construction cost estimate, the optimistic end a few per cent below, and the pessimistic end higher and further away than the optimistic end, because building costs overrun more readily than they undershoot. If you already carry a construction contingency, be careful not to double-count it; a probabilistic cost range and a fixed contingency line are two ways of provisioning for the same risk, and using both in full overstates your buffer.
Sale price, and therefore Gross Realisation Value (GRV), is the revenue side of the same coin. Set the range around your evidenced sales values, and again consider skewing it, because in a softening market prices tend to fall further and faster than they climb in a strong one over the life of a single project. A range of roughly minus 8% to plus 6% around the most likely Gross Realisation Value (GRV) is a reasonable starting point for many build-to-sell schemes, tightened where you have presales locked and widened where the whole revenue depends on a market that is one or two years away.
Sales rate and settlement timing are where a lot of hidden risk lives, because timing drives holding costs and interest. A deal that sells out in three months and one that takes fourteen can carry the same prices and the same build cost yet return very different profits, because the slow one bleeds holding costs and interest while the facility stays drawn. Model the sell-down period as a range rather than a fixed assumption, and let the interest and holding lines recompute off it.
The debt interest rate deserves a range because it is outside your control and it compounds over a long drawn balance. As at its 17 June 2026 decision, the Reserve Bank of Australia held the cash rate target at 4.35%, after lifting it twice earlier in the year, and development facility pricing sits well above that with a lender margin on top. Rather than bet on one rate for a two-year project, model the all-in rate as a range around today’s pricing.
Some inputs are usually better left fixed. Statutory fees, agent commission percentages, professional fees that are already quoted, and anything you have contracted at a firm price add noise without adding insight if you make them variable. The discipline is to vary what is genuinely uncertain and material, and to hold the rest, so the output distribution reflects the risks that actually matter.
Choosing the distribution shape: triangular, beta or normal
The distribution is the shape of the range, and for development inputs the triangular and the beta distribution are the two workhorses, with the normal distribution a distant third. The choice matters more than beginners expect, because it decides how often the model draws values near your most likely figure versus out at the extremes.
A triangular distribution is defined by three numbers you already have to hand: the lowest plausible value, the most likely value, and the highest plausible value. It is the easiest to reason about and the easiest to explain to a funder, which is why it is the default for a lot of property work. The triangular form weights the three points relatively evenly and is a sensible choice when you have limited or roughly equal confidence in your estimates. Its weakness is that it puts more probability out towards the extremes than reality usually justifies, so it can make the tails of your result look fatter than they are.
A beta distribution, more commonly known in project work as the Program Evaluation and Review Technique (PERT) distribution, uses the same three inputs but leans the weight towards the most likely value. The beta shape gives the most likely estimate four times the weight of the optimistic and pessimistic ends, so the calculated expected value is (optimistic plus four times most likely plus pessimistic) divided by six, against the triangular’s simple average of the three. It produces a smoother curve with more probability clustered near the most likely value, which tends to match how construction costs and sale prices actually behave: usually close to estimate, occasionally well off it. The difference is not academic. The output at a given confidence level can shift by roughly 8% to 15% depending on whether you used a triangular or a beta shape, so it is worth stating which you chose and why.
A normal distribution (the symmetric bell curve) is tempting because it is familiar, but it is often the wrong fit for development inputs precisely because it is symmetric. Construction cost overrun and market downturn are not symmetric risks, and forcing them into a symmetric bell understates the downside. Reserve the normal distribution for inputs that genuinely vary evenly around a central value, and prefer a skewed triangular or beta shape for the cost, price and timing inputs that carry one-sided risk. As one Australian risk practitioner puts it, the distribution shape you choose is itself a modelling assumption that changes the answer, so it deserves a conscious decision rather than a default.
A practical rule for most developers: use a triangular distribution when you are sketching a deal quickly and want something defensible, and step up to a beta distribution when the numbers are getting serious and you want the model to respect that the most likely value really is more likely. Skew both towards the downside on cost and timing, and towards the downside on price, so the shape reflects the asymmetry of development risk.
Correlation: the mistake that makes Monte Carlo lie
The most common way a Monte Carlo model gives a dangerously wrong answer is by treating inputs as independent when they move together in the real world. This one issue undoes more simulations than any distribution choice, and it almost always makes the deal look safer than it is. If your model draws each input separately, it assumes a construction blowout and a settlement delay are unrelated coin flips, so the odds of both hitting at once look tiny. On a real site they are not unrelated at all. The trades that blow the budget are often the same problems that blow the programme, so cost overrun and time overrun tend to arrive together.
The revenue side has the same trap. A soft market does not just cut your sale price, it also slows your sales rate, so price and timing move against you in the same conditions. A model that treats them as independent will almost never draw “low price and slow sales” in the same iteration, which is exactly the combination that turns a marginal deal into a loss. By ignoring the link, the model hides the scenario you most need to see.
Handling correlation properly means telling the model which inputs move together and how strongly, using a correlation coefficient between minus one and plus one. You might set construction cost and construction duration at a positive correlation, and sale price and sell-down speed at a positive correlation, so that when the model draws a bad cost it is more likely to also draw a long programme, and when it draws a weak price it is more likely to also draw a slow sell-down. You do not need precise coefficients; even rough correlations are far better than assuming independence. The academic evaluations of Monte Carlo as a decision tool in real estate development stress this exact point, that the method is only as honest as the dependency structure behind it, and that it should build on careful judgement about how the inputs relate rather than being run as a black box. If you take one thing from this guide beyond the base-case point, make it this: an uncorrelated Monte Carlo model on a development is usually too optimistic, and the error is largest exactly where it hurts, in the downside tail.
Reading the output: P10, P50, P90 and your probability of hitting target margin
The output of a Monte Carlo run is a distribution, and you read it through percentiles and probabilities rather than a single figure. A percentile tells you the value below which a given share of outcomes fall. The P50, or 50th percentile, is the median: half the simulated outcomes came in below it and half above. The P10 is the value only 10% of outcomes fell below, so it is a downside marker, and the P90 is the value only 10% exceeded, an upside marker. Quoting a deal as “P50 margin on cost of 15%, P10 of minus 1%, P90 of 29%” says far more than a single base case, because it shows both the central expectation and how wide the outcomes spread.
Two readings matter most to a developer. The first is the probability of hitting your target margin. If your hurdle is 20% on cost, the model can tell you what share of the thousands of runs cleared 20%, and that single percentage is often the most decision-useful number in the whole exercise. A deal that clears its hurdle in 70% of runs is a very different proposition from one that clears it in 25% of runs, even if both show the same base case. The second is the probability of a loss, or of falling below whatever floor would trigger a funding or covenant problem. This is the development equivalent of what finance calls Value at Risk: a governance-ready statement of how bad the bad cases get and how often they happen. “There is a 10% chance of a loss and a 3% chance of losing more than $400,000” is the kind of sentence a Monte Carlo model exists to produce, and the kind an equity partner or a credit committee can actually act on.
A tornado chart is the other output worth reading, because it ranks the inputs by how much each one drives the spread in your result. It shows, at a glance, that construction cost and sale price might account for most of the variance while your professional fees barely register. That ranking tells you where to spend your risk-management effort: lock the presales, fix the build price, tighten the programme, and stop worrying about the inputs that do not move the needle. The distribution tells you how risky the deal is; the tornado chart tells you what to do about it.
A worked example: a six-townhouse project run 10,000 times
Take a small build-to-sell scheme and watch the base case and the simulation diverge. The figures below are illustrative and rounded, chosen to show the method rather than to represent any real site, and your own ranges would drive very different results.
The base case is six townhouses. Gross Realisation Value (GRV) of $8,400,000 (six at roughly $1,400,000), a construction cost of $4,200,000, total development cost including land, fees, holding and finance of about $7,100,000, and a resulting profit of $1,300,000. That is a margin on cost of 18.3% and a margin on revenue of 15.5%. The developer’s hurdle is 20% on cost, so on the base case the deal is close but just short, which is exactly the situation where the odds matter more than the point estimate.
Now set the ranges. Construction cost: most likely $4,200,000, optimistic $4,070,000 (about 3% under), pessimistic $4,700,000 (about 12% over), beta distribution skewed to overrun. Gross Realisation Value (GRV): most likely $8,400,000, range about minus 8% to plus 6%, skewed down. Sell-down: most likely six months, optimistic three, pessimistic fourteen, which reprices holding costs and interest. Debt rate: a range around current pricing. Then add correlation: construction cost positively linked to construction duration, and sale price positively linked to sales rate, so bad-cost iterations tend to run long and weak-price iterations tend to sell slowly. Run it 10,000 times.
The kind of output a run like this tends to produce tells a story the base case could not. The median (P50) margin on cost might land around 15% to 16%, two to three points below the 18.3% base case, purely because the cost, price and timing ranges all lean down. The probability of clearing the 20% hurdle might be only about 20% to 25%, so the deal that looked “close to 20%” actually beats it only one run in four or five. The P10 margin might sit near zero or slightly negative, and the probability of an outright loss might be roughly 8% to 12%. The P90 might reach 27% or 28% on a good run where costs held, the market firmed and the stock sold fast.
Read together, those numbers reframe the decision. The deal is not unviable, but it is not the 18% deal the base case implied either. It is a deal with a realistic median in the mid-teens, a one-in-four chance of hitting the hurdle, and a roughly one-in-ten chance of losing money. A developer armed with that can act: push for firmer presales to lift and tighten the Gross Realisation Value (GRV) range, negotiate a fixed-price build to cut the cost tail, or reprice the land so the whole distribution shifts up. The base case offered no such handles, because it hid the very spread that the decision turns on. This is also why the median came in below the base case: the downside on each input was deliberately set fatter than the upside, so the centre of the outcome cloud sits below the single optimistic point.
Monte Carlo against sensitivity and scenario analysis: which earns its place
Monte Carlo is not the right tool for every deal, and reaching for it on a simple project is wasted effort. The honest hierarchy runs from cheap and quick to thorough and slow, and most developments are well served long before the top of it.
For a straightforward site with firm costs and a short sell-down, a one-variable-at-a-time sensitivity analysis usually answers the question. Flex construction cost and sale price by a few per cent each way, see how the margin holds, and you have most of what you need. A small set of named scenarios adds a downside and an upside without much more work. Tools built for developers make this the default: a good feasibility platform runs a sensitivity matrix that scales revenue and cost by percentage steps and compares a handful of preset scenarios side by side against your target margin. For a large share of deals, that deterministic view is enough to make the call, and it takes minutes rather than an afternoon.
Monte Carlo earns its place when the stakes and the uncertainty are both high. The deals that justify it tend to share features: a long timeline where a lot can change before completion, a big or lumpy capital commitment where a bad tail is survival-threatening, several genuinely uncertain inputs interacting at once, or an equity partner or lender who wants a probabilistic statement of risk rather than a single number. A two-year, multi-stage project with unsold stock exposed to a market that is eighteen months away is a Monte Carlo candidate. A quick subdivision with three lots presold is not. The property research literature makes the same point, that probabilistic methods are most valuable where deterministic appraisal is weakest, on complex, uncertain, capital-intensive schemes, and adds a caution worth keeping: a simulation should extend careful judgement, not replace it.
It is worth being clear about where the built-in tools stop. A feasibility platform that runs a defined sensitivity matrix and named scenarios is doing deterministic analysis: a fixed set of cases, each calculated once. That is different from a Monte Carlo simulation, which draws thousands of random combinations and returns a probability distribution. The two are complementary. Most developers do the deterministic work inside their feasibility tool for the day-to-day call, and reach for a spreadsheet or a specialist simulation add-in for the minority of deals that warrant a full probabilistic run. Knowing which question you are asking keeps you from over-engineering a simple deal or under-analysing a risky one.
How to build one: spreadsheet, add-in, or feasibility platform
You can run a credible Monte Carlo simulation in three ways, and the right one depends on how often you will do it and how much rigour the deal demands. All three run on top of an existing feasibility model, so the quality of the underlying feasibility spreadsheet or model sets the ceiling on how good the simulation can be.
The first way is plain Excel or Google Sheets. You build your feasibility as normal, replace the key inputs with formulas that draw a random value from a range, and use a data table or a short macro to recalculate the sheet thousands of times while recording the profit each run. This is how many developers start, it costs nothing beyond the spreadsheet you already have, and Microsoft documents the core technique directly. The limits show up with correlation and with distribution shapes: modelling a proper beta curve or a correlation structure by hand in raw Excel is fiddly and easy to get subtly wrong.
The second way is a simulation add-in that sits on top of Excel and handles the sampling, the distributions and the correlations for you. These tools let you assign a triangular, beta or other distribution to any input cell, set correlations between them, run thousands of iterations at speed, and produce the percentile output and tornado charts described above. For a developer running probabilistic analysis regularly, an add-in removes most of the manual error and makes the correlation step, the one that matters most, straightforward to set up.
The third way is to keep the deterministic modelling in a purpose-built feasibility platform and use it to feed the simulation. The platform holds the feasibility, runs the sensitivity matrix and scenario comparison for the everyday decision, and lets you duplicate and compare scenarios quickly. When a deal warrants a full Monte Carlo run, you export or rebuild the model’s logic where the sampling engine lives. This keeps the single source of truth for the deal in one place while acknowledging, honestly, that the probabilistic sampling itself is a separate step. Whichever route you choose, the discipline is the same: get the feasibility right first, vary only the inputs that are genuinely uncertain and material, set sensible distributions and correlations, and read the output as probabilities rather than promises.
Does it change by state, or in New Zealand?
The Monte Carlo method itself does not change anywhere, because it is a modelling technique rather than a rule, so there is no state-by-state legislation to track. What changes across the states, territories and New Zealand is the input ranges you feed it, and those can differ enough to move a deal from comfortable to marginal.
Construction cost escalation is the clearest example of a range that shifts by market. Rider Levett Bucknall’s 2026 outlook puts national escalation at 4% to 6% but spreads it unevenly: it forecasts stronger growth in Perth, Adelaide, Brisbane and regional Queensland where defence, health and infrastructure pipelines are tightening capacity, with the Gold Coast and Townsville among the highest, and softer growth in Canberra, while Sydney and Melbourne sit around the national middle. A construction cost range built for a Perth project should therefore lean higher and wider than one built for a Canberra project, even for an identical building. Holding-cost ranges also shift with state settings, because land tax and council rates differ, so the land holding cost line that a slow sell-down inflates is heavier in some states than others. The technique is uniform; the numbers you put into it are local.
New Zealand developers use Monte Carlo in exactly the same way, on the same inputs, with two timing wrinkles worth building into the ranges. Consent timing carries real uncertainty, so the sell-down and holding assumptions should reflect the spread in how long a resource consent can take, particularly through a period of planning-system reform. And the tax treatment of a quick resale can change the after-tax outcome, so where the exit timing straddles a threshold, that is a variable worth modelling rather than assuming. The core discipline does not change across the Tasman: vary what is genuinely uncertain, respect the correlations, and read the odds rather than the point estimate.
Where Monte Carlo misleads, and how to keep it honest
A Monte Carlo simulation can produce a confident, precise, professionally formatted answer that is completely wrong, and the failure modes are predictable enough to guard against. The output looks authoritative because it is quantified, which makes a bad model more dangerous than an honest guess.
The first failure is garbage in, precise out. The model can only sample the ranges you give it, so if your ranges are too narrow, too optimistic or simply wrong, the output inherits every error and dresses it up as a probability. A simulation that says “8% chance of loss” is only as good as the cost, price and timing ranges behind it, and no amount of iterations fixes a bad range. Ground the ranges in evidence: quantity surveyor estimates, comparable sales, current escalation data, real consent timeframes.
The second failure is ignoring correlation, covered above, which almost always makes the deal look safer than it is by hiding the combined downside. If you do nothing else sophisticated, correlate cost with time and price with sales rate.
The third failure is false precision. Reporting a “10.4% probability of loss” implies a confidence the model does not have. The honest reading is “roughly a one-in-ten chance”, and the value of the exercise is the order of magnitude and the shape of the risk, not the decimal place. Treat the percentiles as directional, not exact.
The fourth failure is treating the median as a promise. A P50 margin of 15% means half the outcomes were worse, not that you will make 15%. The distribution exists precisely because no single number is guaranteed, and a developer who banks the P50 has simply swapped one point estimate for another. Read the whole distribution, plan for the P10, and size your equity and contingency so the downside tail is survivable rather than fatal. Used with that discipline, Monte Carlo is one of the more honest tools a developer has, because it is the one that refuses to pretend the future is a single number.
The bottom line
Monte Carlo simulation turns a feasibility from a single answer into a set of odds, and for the right deal that is a better basis for a decision. It takes the ranges you already half-carry in your head for cost, price and timing, runs the feasibility thousands of times across them, and tells you how likely you are to hit your margin and how bad the bad cases get. Its value is not the precision of any one percentage; it is that it refuses to hide behind a base case that was only ever one outcome out of thousands, and usually an optimistic one.
For most everyday deals, a disciplined sensitivity analysis and a few named scenarios will answer the question, and the built-in tools in a feasibility platform handle that well. Save Monte Carlo for the long, large, uncertain projects where the tail could sink you, build it on a sound feasibility, set honest ranges and correlations, and read the output as probabilities. The method is only as good as the judgement behind the inputs, but applied with that judgement it gives a developer something no single number can: a clear-eyed view of the odds before the capital goes in.
This guide is general information for property developers and does not constitute financial, investment or professional advice. Figures are illustrative, ranges and outcomes depend entirely on your specific project, and current costs, rates and market conditions shift over time. Model your own deal and take professional advice before committing capital.