The runway model is one tab in one spreadsheet and there is exactly one cell in it that anybody actually looks at. Everything else exists to produce that cell. It contains a month and a year, and once you have seen it you cannot unsee it.

For a long time I treated that cell as the deadline. It is not the deadline. It is roughly six to nine months after the deadline, and confusing the two is how founders end up negotiating from a position where the only honest answer to how much runway do you have is a number that makes the terms worse.

The real deadline is earlier than the cell

Raising money takes time. Building a list, first meetings, partner meetings, diligence, documents, close. Three months is fast. Six months is normal. Longer is common and not a sign of failure.

You also cannot raise well with two months left. Investors ask, you answer, and the conversation changes shape immediately. Not because anyone is cruel, but because a company that must close in six weeks has a different set of options than one that could walk away, and everybody in the room understands that.

So the working deadline is the money-out month minus the fundraising duration minus a buffer. If your cell says November and raising takes five months, your real deadline is around April, with the assumption that you will not be building product in April. Founders consistently discover this in month three of a raise.

The twenty-month problem

There is a specific timing assumption baked into a lot of seed-stage plans and it has quietly stopped being true.

The median gap between closing a seed round and closing a Series A has stretched considerably, on recent measures to around twenty months. That is a substantial change from the twelve to fifteen month planning assumption most founders inherited from earlier cohorts, and it is not a temporary market condition so much as a rise in the bar. Series A now expects repeatability, typically somewhere in the range of one to three million in annual recurring revenue with evidence that acquisition can be repeated rather than recounted.

The arithmetic follows. If you raise a seed and plan twelve months of runway to reach a Series A that on average arrives at twenty, you have planned a crunch and scheduled it for a moment when you will also be trying to sell. Plan for twenty-four to thirty months, which usually means either raising more or spending less, and spending less is the option you control.

Two clocks, running at different speeds

Here is the modeling error I see most often, and I made it myself: one burn number.

An AI company has two kinds of burn and they behave nothing alike.

Headcount burn. Salaries, contractors, the tools people need. You control it completely. It moves in steps, because hires are discrete events. It is sticky in the downward direction, both practically and morally. It is almost perfectly forecastable, which is why finance people love it.

Compute burn. Inference and everything metered per request. Your customers control it. It moves continuously, it is only partly forecastable, and its defining property is that it rises when things go well.

Blend those into one line and you get a number that is wrong in both directions. It understates your risk in a good month and overstates it in a quiet one.

The scenario worth modeling explicitly is the uncomfortable one. Growth accelerates. Usage deepens. Compute burn rises immediately, because inference is consumed the moment the work happens. Revenue lags, because you invoice monthly or quarterly and business customers pay on their own schedule, which is thirty to sixty days after that. For a period of weeks, sometimes months, your runway is getting shorter precisely because you are winning. Nobody who learned software finance in the subscription era expects that shape, and it has caught out companies whose only mistake was growing quickly.

The number investors will ask for

Growth rate on its own has stopped being a sufficient answer, because anybody can buy growth. The question now is what the growth cost.

Burn multiple is net cash burned divided by net new annual recurring revenue over the same period. If you burned two million and added two million of net new recurring revenue, your burn multiple is one. Below one is excellent and rare. One to one and a half is a good business. Above two needs an explanation, and above three needs a plan rather than an explanation.

It is a better question than growth because it is difficult to flatter. It captures pricing, retention, sales efficiency and cost of goods in a single ratio, and it penalizes exactly the behaviors that look like traction and are not.

Calculate it quarterly. Show it before you are asked, because a founder who volunteers their burn multiple is telling the room something about themselves independent of the number.

The question almost nobody calculates

If you never raise another round, and your current growth rate and current cost trajectory continue, do you reach profitability before the money runs out?

That is the whole question. It has a yes or no answer and it takes an hour to compute properly. In my experience most founders have never done it, and a meaningful number of them assume the answer is no when it is actually yes with two decisions changed.

What makes it valuable is not the answer. It is what it does to the conversation. A founder who knows they can survive without raising is negotiating. A founder who does not know is hoping. Investors can tell the difference within about ten minutes, and it is the single largest determinant of terms that founders treat as unchangeable.

Three ways this goes wrong

You model revenue as booked rather than collected. Signed is not invoiced, invoiced is not paid, and the gap between them is where small companies die with healthy-looking pipelines. Model cash, on the date it arrives, with realistic terms.

You cut compute instead of headcount, or headcount instead of compute, without checking which is which. Under pressure teams reach for the lever that is easiest emotionally rather than the one that is largest. Compute burn is frequently reducible by thirty percent or more through routing and context discipline, without anyone losing a job. That work should be done before any conversation about people, and it usually is not.

You update the model quarterly. Cost per query moves weekly, prices move, and one shipped feature can change your unit economics overnight. A runway model refreshed four times a year is a historical document. Monthly is the minimum, and the person who maintains it should be a founder, not somebody a founder asks.

Headcount burn you control. Compute burn your customers control. Model them separately.

Tomorrow: the pull request nobody reviewed, and the ninety-day reckoning that follows it.