Cash Flow & Runway Analysis for Startups
A startup financial model has one honest purpose, and it isn't predicting the future — every model's specific numbers will be wrong, and everyone sophisticated who reads it knows that. Its purpose is to make your assumptions explicit, connected, and testable: if we acquire customers at this cost and they behave this way, then cash does this. That's what investors are actually evaluating in your model — whether you understand your own machine — and it's what makes the model useful long after the raise, as the standing answer to "can we afford this?" Here's how to build one that does that job, step by step.
Step 1: Choose Bottom-Up as Your Engine (Keep Top-Down as a Check)
Two philosophies exist. Top-down starts from market size and asserts a capture percentage ("1% of a $10B market"); bottom-up starts from operational drivers — leads, conversion rates, reps, pricing — and builds revenue from the mechanics. Build bottom-up. Top-down projections are, in the classic phrase, not particularly useful as forecasts, because the capture percentage is an assertion with no machinery behind it; their legitimate role is as a sanity check and a TAM narrative for the pitch. A bottom-up model, by contrast, produces numbers you can manage against: if the model says 40 demos a month convert at 20%, and reality says 25 demos at 15%, you know precisely which assumption broke and which lever to work.
Step 2: Build the Revenue Engine From Real Drivers
Start with how a dollar of revenue is actually manufactured in your business and encode that chain: for a sales-led SaaS company, pipeline → win rate → new ARR → plus expansion, minus churn; for self-serve, traffic → signup rate → activation → conversion → ARPU. Every arrow is an assumption cell you'll later test. Two disciplines here separate credible models from hopeful ones: growth rates must be outputs of the driver chain, not inputs (a model where you type "15% monthly growth" into a cell has skipped the entire point), and each assumption should trace to evidence — your actuals where they exist, industry benchmarks where they don't, clearly labeled as such.
Step 3: Build Costs the Same Way
Expenses get the same driver treatment. Headcount is the big one — model it as a hiring plan by role and start date, with fully loaded costs (salary plus roughly 1.2–1.4× for taxes, benefits, and tools), because payroll is typically 70%+ of a startup's spend and hiring timing is your biggest cash lever. Separate cost of revenue (hosting, support, payment processing) from operating expenses so gross margin falls out honestly, tie variable costs to the drivers that create them (customer count, transaction volume), and don't forget the lumpy items — insurance, annual software, legal — that a smooth monthly average hides.
Step 4: Connect the Three Statements
A driver model that stops at a P&L forecast answers profitability but not survival. The full structure links three statements: the income statement (is the model profitable?), the balance sheet (what do we own and owe — where receivables, payables, and deferred revenue live), and the cash flow statement (are we generating or consuming cash, and when do we run out?). The linkage is where accrual reality enters: revenue booked isn't cash collected, and for a SaaS company with annual prepays the gap is enormous — which is why burn and runway must come off the cash flow statement, not the P&L. The model's single most-watched output is the cash line and the month it crosses zero; everything else in the workbook exists to make that number credible.
Step 5: Wire In the Metrics That Get Asked About
Build a summary tab that computes, live from the model, the numbers every investor conversation will reach for: monthly burn and runway, gross margin, CAC and CAC payback, LTV (with the honest caveat that early-stage LTV is an estimate wearing a suit), revenue per employee, and — for SaaS — ARR, net revenue retention, and churn. Two of these deserve founder attention beyond fundraising: revenue per employee against expense per employee is the crudest but fastest efficiency check as you scale, and the accumulated-losses line answers "how much do we actually need to raise, and when" — which should be an output of the model, not a round number chosen for the pitch.
Step 6: Make It Scenario-Ready
A model you can only run once is a poster. Structure the assumptions on a dedicated inputs tab so that base, upside, and downside cases are a handful of cell changes — slower sales cycles, higher churn, a delayed raise — and you can answer "what if" in a board meeting rather than a week later. The downside case matters most: the model's practical job between fundraises is telling you, early, the date on which the current plan stops working, so the response can happen while options still exist.
The Craft Rules That Keep It Trustworthy
Mechanical hygiene is what lets others (and future-you) trust the workbook — the full list is in financial modeling do's and don'ts, but the ones that prevent the most damage: no hardcoded numbers buried in formulas (every input lives in a labeled assumption cell); consistent formulas across all time periods so extending the horizon is a drag, not a rebuild; one sign convention throughout; the standard color code (blue inputs, black formulas, green cross-sheet links); and nothing hidden — concealed tabs and formulas read as concealment in diligence, because sometimes they are. Simple and consistent beats clever every time someone else has to read the thing, and someone else always eventually has to read the thing.
Keep It Alive
The model's value compounds only if it stays connected to reality: monthly, after the books close, replace forecast with actuals and interrogate the variances — every gap between the model and reality is either an execution problem or an assumption you've now learned is wrong, and both are worth knowing promptly. Fold what you learn into next quarter's assumptions and the model becomes what it's supposed to be: not a fundraising artifact, but the company's working theory of itself, versioned. SaaS-specific structure gets its own treatment in SaaS financial modeling best practices — and if the model you need is diligence-grade and the deadline is a term sheet, building it alongside a fractional CFO is the difference between presenting a model and defending one.
