Mixed-use deals are genuinely messy. You've got residential above retail, maybe some office thrown in, different lease structures, different cap rates per use and your investor wants to know what happens to returns if rent drops 10% or construction costs spike. That's where a sensitivity table stops being a "nice to have" and becomes the thing that saves you from confidently presenting a deal that falls apart under light questioning.
First, Why Mixed-Use Makes Sensitivity Analysis Harder
In a straightforward apartment building, you're mostly toggling rent per unit and exit cap rate. With mixed-use, each component has its own income driver, its own vacancy assumptions, and sometimes its own financing treatment. A 10% rent decline in your ground-floor retail hits completely differently than the same drop in your residential floors especially if your retail is NNN and your residential is gross.
So your sensitivity table can't just be a single two-variable grid. You either need component-level tables, or you need a model that aggregates them cleanly enough that the blended output still tells a useful story.
Step 1: Lock Down Your Base Case Numbers First
Before you touch a sensitivity table, you need a model that actually works. That sounds obvious, but a lot of people try to run sensitivities on a half-built model and wonder why the outputs look weird.
For a mixed-use project your base case needs at minimum:
- GBA breakdown by use (residential, retail, office, parking)
- Revenue assumptions per use residential rent per unit, retail rent per sqft, occupancy by component
- Hard and soft cost totals, development timeline
- Stabilized NOI per component, then blended
- Exit cap rate or sale price assumption
- Financing structure construction loan, permanent debt, equity stack
- Your IRR and equity multiple at base
Once that's solid, you're ready to run scenarios against it. Tools like EstateMaster have been around long enough that their mixed-use module handles this component-by-component breakdown natively so if you're modeling in something purpose-built rather than Excel, the base case structure is already baked in.
Step 2: Pick Your Two Variables
A sensitivity table is a grid:- rows are one variable, columns are another, and every cell shows your output metric (usually IRR, equity multiple, or profit margin).
For mixed-use, the most useful variable pairs I've seen are:
Residential rent vs. exit cap rate:- captures both income and valuation risk in one table. This is the one every equity partner wants to see.
Construction cost variance vs. retail rent:- useful when your retail is less certain (pre-leased vs. speculative) and your GC bid has some range to it.
Residential occupancy vs. retail occupancy:- shows how bad things have to get on both sides simultaneously before the deal breaks.
Equity contribution vs. construction cost:- if you're stress-testing the capital stack.
Don't try to do all of these in one table. Pick the two that represent the most meaningful uncertainty in your specific deal. If your retail is already pre-leased at a fixed rate, retail rent isn't a relevant sensitivity variable for you right now.
Step 3: Define Your Range Increments
Most sensitivity tables use 5 or 7 data points per variable, stepping in equal increments around the base case.
For a residential rent assumption of $2,800/unit, you might step in $150 increments: $2,200 / $2,350 / $2,500 / $2,650 / $2,800 / $2,950 / $3,100
For exit cap rate at 5.25%, stepping in 25bps:
4.25% / 4.50% / 4.75% / 5.00% / 5.25% / 5.50% / 5.75%
The base case cell sits in the middle of the grid. The ranges should represent realistic stress not apocalyptic scenarios, but not cosmetic either. If your market has seen 15% rent swings in the last cycle, your table should probably cover at least that range.
Step 4: Build the Table (Excel vs. Dedicated Tools)
If you're in Excel, the cleanest approach for sensitivity tables is the Data Table function under What-If Analysis. You set up a row input cell and a column input cell, highlight the grid, and it runs every combination without you having to do it manually. The trick is making sure your model has clean cell references that actually link back to the inputs if your residential rent is hardcoded in 12 different places, the table won't work right.
This is also where a lot of people hit a wall with mixed-use models specifically. If your model has three separate income schedules that all need to respond to the same input shift, you need an intermediate cell that ties them together. Build it right and the table works in seconds. Build it messily and you'll spend an hour debugging.
If you're using dedicated feasibility software, this is much faster. Aprao, for instance, is built for development appraisals and lets you run scenario comparisons without the manual table setup you define the variable range and it handles the grid. Similarly, Deepblocks does this at the project concept stage, which is useful if you're still in early feasibility and don't want to over-engineer the model yet.
Northspyre leans more toward active project cost tracking and budget management, but if your sensitivity is focused on cost variance (which it often should be on complex mixed-use deals), pulling actual cost data from there into your sensitivity assumptions gives you ranges grounded in real project data rather than guesses.
Step 5: Choose Your Output Metric Carefully
IRR is the default, but it's not always the most useful. Here's when to use what:
IRR use when you're talking to equity partners who have a hurdle rate. They want to know if you clear it under stress.
Equity Multiple use when the hold period might vary or when your LP cares more about total return than annualized rate.
Profit on Cost / Development Margin use in early-stage feasibility, before you've locked down the capital structure. Simpler, harder to game.
Levered vs. Unlevered show both if you can. A deal that looks okay unlevered but breaks levered at mild stress tells you something important about the financing structure.
For a mixed-use project where you're presenting to a lender or a value-add equity partner, I'd show IRR and profit-on-cost side by side. Different people anchor to different metrics.
Step 6: Color Code It So the Story is Obvious
This sounds minor but it matters. A raw table of numbers requires someone to read every cell. A color-coded table communicates instantly.
Simple convention:
Green:- IRR above your target (say, 15%+)
Yellow:- IRR within acceptable range (10–15%)
Red:- IRR below hurdle or deal is structurally broken
In Excel this is a two-minute conditional formatting job. In most dedicated tools it's automatic. Either way, when you hand this to someone in a meeting they should be able to look at it for five seconds and understand where the deal is robust and where it isn't.
A Note on AI-Assisted Feasibility
This is moving fast. feasibilitypro.ai is one of the newer tools specifically targeting this workflow where you input project parameters and it generates scenario outputs including sensitivity grids without you having to build the model architecture yourself. The pitch is speed at early feasibility, which is legitimate. If you're running 10 sites through initial screening, spending four hours building a model per site is genuinely not the right use of time.
The caveat and this applies to any automated feasibility tool is that the assumptions it uses need to match your market. Output is only as good as the input assumptions, and local rent trends, cap rate compression, construction cost premiums, and land residuals vary enough that you should always sanity check the numbers against deals you've actually underwritten or closed in the same market.
What the Table Should Actually Tell You
Once you've got the grid, here's what to look for:
Where's the break-even line? Find the cells where your IRR crosses the hurdle rate. That diagonal line tells you the worst combination of your two variables the deal can tolerate.
Is the deal sensitive to one variable much more than the other? If moving the cap rate 50bps kills the deal but a 15% rent decline barely moves the needle, that's telling you something about where your real risk is.
How much cushion do you have? If your base case is in the middle of the green zone, that's a different deal than one where base case is sitting one cell from red.
Does this match your gut read on the market? If your table says the deal works under a lot of scenarios but you know retail leasing in that submarket has been dead for two years, the table is not a substitute for judgment.
The Whole Point
A sensitivity table for mixed-use isn't complicated it's two variables, a grid, and a clean base case model. The reason people struggle with it is usually that the underlying model isn't structured well enough to run clean scenario analysis, or they're trying to show sensitivities on too many variables at once and it becomes noise.
Get the base case right, pick the two variables that actually matter for your deal, run the grid, and color it. That's the whole thing. Thirty minutes if your model is already built. And when someone in the room asks "what happens if construction costs run 12% over?" you just point at the table.
Top comments (0)