Strategy & Planning

How to run a scenario analysis for a strategic decision as Real Estate Founders

Strategy & PlanningFor Real Estate Founders2 apps12 steps~24 min to set up

You're modeling a potential acquisition — say, a 24-unit multifamily in a market you've been watching — and your 'scenario analysis' is a Google Sheet with hardcoded assumptions your associate built six months ago. You change the cap rate in one cell and three linked tabs break. You've got Plaid connected to your operating account, Stripe collecting management fees, and QuickBooks holding your actual P&L — but none of that feeds the model. So you're running scenarios on stale numbers, by hand, every time a deal or a rate environment changes. You make a pricing or timing decision — raise capital now or wait, sell asset A to fund asset B — and you're doing it on gut and a broken spreadsheet.

Build this on Starch → See the apps used

Strategy & PlanningFor Real Estate Founders2 apps12 steps~24 min to set up

Outcome

What you'll set up

A live scenario analysis dashboard that pulls your actual bank feed balances and fee revenue into the baseline — so you're modeling from real numbers, not last quarter's exports

Side-by-side scenario comparisons for real estate decisions: acquisition financing structures, disposition timing, hiring a property manager vs. staying self-managed, or delaying a capital raise by two quarters

A repeatable process so you can re-run the model any time a deal changes, a rate moves, or an LP asks 'what does our runway look like if occupancy drops to 88%?'

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Scenario Analysis Runway Analysis

Data sources & config

Starch syncs your Plaid bank feed data on a schedule (transactions, balances, cash position) and syncs your Stripe data on a schedule (management fee charges, recurring invoices, payouts). These live sources become the baseline for every scenario — you're adjusting assumptions on top of actual numbers, not last month's export. QuickBooks can also be connected via Starch's scheduled sync to pull entity-level data like bills, vendor payments, and journal entries if you want tighter cost categorization in the model.

Prompts to copy

Connect my Plaid bank feeds and Stripe management fee revenue as the baseline. Build me three scenarios: (1) we acquire the Denver asset in Q3 at 65% LTV, (2) we delay the acquisition to Q1 and deploy the capital as a bridge loan instead, (3) we sell the Phoenix asset in Q4 and use proceeds to pay down the credit line. Show runway, net burn, and break-even month for each.

Using my Runway Analysis baseline, model what happens to my operating runway if occupancy across the portfolio drops from 94% to 88% for two consecutive quarters. Assume management fee revenue tracks occupancy linearly.

Show me a scenario where I hire a full-time asset manager at $120k salary starting in Q2 vs. keeping the current third-party PM arrangement at 6% of gross rents. Factor in current revenue from Stripe and burn from Plaid and project 18 months forward.

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Plaid from the Starch integrations panel — Starch syncs your operating and reserve account balances and categorized transactions on a schedule, so your cash position is always current.

2 Connect Stripe so Starch syncs your management fee revenue, recurring charges, and payouts — this becomes the revenue line in your baseline without any manual entry.

3 Optionally connect QuickBooks through Starch's scheduled sync to pull bills, vendor payments, and journal entries for more granular expense categorization by property or entity.

4 Open the Scenario Analysis app from the App Store — the baseline is auto-populated from your Plaid and Stripe data. Review it and confirm the numbers look right before building scenarios.

5 Describe your first scenario in plain language: 'Assume we close the Denver acquisition in July at $4.2M, financed at 65% LTV with a 7.1% rate. Add the debt service to monthly burn and add 12 units of fee revenue at 8% of gross rents starting in August.'

6 Add a second scenario that represents your alternative path — delaying the acquisition, a disposition, a capital raise, or a change in staffing — described the same way in plain language.

7 Add a stress scenario: 'What if occupancy drops to 88% portfolio-wide for Q3 and Q4? Reduce Stripe fee revenue proportionally and hold all other costs flat.'

8 Review the side-by-side output: runway in months, net monthly burn, and projected break-even date for each scenario. Starch surfaces which assumptions drive the biggest variance.

9 For LP or board communication, note which scenario you're treating as base case and why — Starch lets you annotate the model so you're not re-explaining it from scratch in every investor call.

10 When a deal falls through, rates shift, or an LP asks a new question, return to the app and add or update a scenario in plain language — you're not rebuilding the model, just adjusting assumptions on a live baseline.

11 Use the Runway Analysis app alongside Scenario Analysis for the daily 'where do we stand' view — Scenario Analysis is for decision points, Runway Analysis is for the ongoing operating picture.

12 Export or share specific scenario outputs with your capital partners or asset management team when you need to show your work without giving them access to the full model.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

Q3 2026 Acquisition Decision — Denver 24-Unit vs. Bridge Deployment

Sample numbers from a real run

Current cash (Plaid, all operating accounts)	1,840,000
Monthly management fee revenue (Stripe, 3-property portfolio at 8% of gross rents)	28,400
Monthly operating burn (payroll, G&A, debt service — Plaid categorized)	41,200
Net monthly burn (baseline)	-12,800
Scenario A: Denver acquisition — added debt service at 7.1% on $2.73M loan	-16,175
Scenario A: Added fee revenue from 12 Denver units at 8% of $18k gross rents	1,440
Scenario B: Bridge loan deployment — $1.2M at 11% annualized, interest income	11,000

At $1.84M cash and $12,800 net monthly burn, your baseline runway is about 143 months — you're not burning the house down. But the Denver acquisition changes the math. Scenario A shows that adding $16,175/month in debt service offset by only $1,440 in new fee revenue pushes your net burn to $27,535/month, dropping runway to 67 months. That's still fine on paper, but it assumes 94% occupancy and no capital calls from existing LPs. In Scenario B, you skip Denver and deploy $1.2M as a bridge loan at 11% — that generates roughly $11,000/month in interest income and actually improves your net position to a $1,800/month surplus. Scenario C layers in the stress test: if portfolio occupancy drops to 88%, Stripe fee revenue falls by $3,808/month. Under Scenario A with that occupancy hit, net burn climbs to $31,343 and runway compresses to 59 months. The model makes the decision concrete: Denver works financially but it's the least resilient path if anything softens. You bring Scenario B to the LP call as the preferred near-term deployment and set a Q1 trigger to revisit Denver if rates move.

Measurement

How you'll know it's working

Months of operating runway under each scenario (base, upside, stress)

Net monthly burn inclusive of debt service, segmented by property entity

Management fee revenue as a % of gross rents across the portfolio (occupancy sensitivity proxy)

Break-even occupancy rate — the occupancy level at which fee revenue covers G&A without depleting reserves

Debt service coverage ratio (DSCR) per asset under acquisition scenarios

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Google Sheets / Excel with manual Plaid exports

You can build any model you want, but the baseline is always stale — you're exporting CSVs and pasting data every time you want a current number, which means you stop updating the model as often as you should.

Argus Enterprise

Purpose-built for property-level cash flow modeling and appraisal work, but it's expensive, slow to set up, and disconnected from your operating accounts — it doesn't know what's actually hitting your bank feed today.

Juniper Square

Strong for LP reporting and fund accounting, but scenario modeling for operational decisions — hiring, timing, structure — isn't what it's designed for, and it won't pull from your Plaid or Stripe data.

Mosaic or Causal (SaaS FP&A tools)

Good general-purpose FP&A platforms, but they're built for SaaS metrics (ARR, churn, headcount) and require meaningful setup to model real estate-specific constructs like debt service by asset, occupancy-linked revenue, or disposition proceeds.

On Starch RECOMMENDED

One platform — scenario planning, runway analysis all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

Does Starch pull from my actual bank accounts, or do I have to upload numbers manually?

Starch syncs your Plaid-connected bank accounts on a schedule — transactions, balances, and categorized spend. You connect once and the baseline in Scenario Analysis reflects real cash position from that point forward. No CSV uploads, no manual entry.

My portfolio is structured across multiple LLCs. Can Scenario Analysis handle that?

You can describe the structure in natural language when you set up the model — 'entity A holds the Phoenix asset, entity B holds Denver, management company bills 8% to both.' Starch will build the model to that structure. You can also connect multiple Plaid accounts (one per entity) if your banking is separated that way.

I use QuickBooks for my P&L but Plaid for cash. Which one should I use?

Both, ideally. Starch syncs QuickBooks entity-level data (bills, vendor payments, journal entries, invoices) on a schedule, and separately syncs your Plaid bank feed. The two give you different things: QuickBooks gives you accrual-basis cost categorization; Plaid gives you actual cash movement. For scenario analysis you generally want the Plaid cash data as the baseline and QuickBooks for expense detail.

Starch isn't SOC 2 certified — is it safe to connect my banking data?

Starch is not SOC 2 Type II certified today, which is worth knowing. The Plaid connection uses the same OAuth flow that powers most consumer and business banking apps — Starch reads transaction and balance data but does not have the ability to move money. Whether that's acceptable depends on your firm's data policies; it's an honest tradeoff to weigh.

What if my lender or LP wants to see the model, not just the output?

You can share specific scenario outputs — the numbers, assumptions, and projections — from within Starch. You're not giving anyone access to your connected accounts. If a capital partner needs a traditional Excel file to satisfy their own process, that's a gap to be aware of: Starch is a live dashboard environment, not a spreadsheet you can hand off in .xlsx format.

Can Starch model a disposition — selling an asset and redeploying proceeds?

Yes. You describe it: 'Assume we close the Phoenix sale in September for $3.8M net of closing costs. Add that to the cash balance on October 1 and remove the associated debt service and management fee revenue. Show runway and burn under this scenario.' Starch builds the scenario from that description against your live baseline.

I don't use Stripe — I collect management fees through ACH directly. Will the baseline still work?

Yes. If your management fee deposits show up in your Plaid-connected operating account, Starch can see them as bank transactions. You'd describe which transaction categories represent fee revenue when setting up the baseline, and Starch uses those as the revenue line. The Stripe connection is valuable if you want invoice-level detail, but it's not required.