After we cut Realm from 68 to 24 people, I read everything I could find about capital efficiency and default-alive thinking. I was trying to understand how I had gotten to a position where I had no survivable path without a round that didn't close.
The answer, in retrospect, was simple: I had been measuring the wrong thing. I was tracking runway — how many months of cash remaining — but not the underlying question runway is supposed to answer. Runway is a static measurement. Default-alive is a dynamic one.
The difference matters. A company can have twelve months of runway and be structurally incapable of reaching cash flow positive before that runway expires. That company is default-dead, regardless of what the runway number says. A company can have six months of runway and a clear path to profitability in five. That company is default-alive.
Here is the calculation.
Monthly burn: Your total operating expenses per month, including salaries, infrastructure, and everything else that leaves the bank account.
Monthly revenue: Actual recognized revenue, not pipeline, not commitments. What hits the bank.
Monthly revenue growth rate: The month-over-month percentage by which revenue is growing. This is the critical variable.
Default-alive calculation: At your current burn and your current growth rate, will you reach break-even before you run out of money?
The math is straightforward, which is why it's so easy to avoid running it. If the answer is yes, you're default-alive. If the answer is no, you're default-dead. Most founders who are default-dead know it at some level — they're just not forcing themselves to look at it directly.
When we finally ran the actual numbers at Realm — after the C-round conversations had gone cold — the picture was stark. At 68 people with the burn we were carrying, we had roughly nine months of runway. But our revenue growth had been strong without being transformative, and the break-even point on our model was well past the runway window. We weren't nine months from default-alive. We were nine months from zero, with no survivable path in between. The number I remember is how small the gap looked when we finally wrote it on a whiteboard: the break-even headcount was somewhere around 20 to 25 people. We were at 68. There was no version of this that didn't involve significant cuts. The calculation didn't tell us something we didn't know — we knew the market had tightened and the round wasn't closing. What it did was eliminate ambiguity about what we had to do.
The reason this calculation gets avoided is that it produces uncomfortable answers.
A company at seed stage with $500K in MRR, growing 20% month-over-month, and $200K in monthly burn is default-alive — even though it has less than six months of runway at current burn. The math says it reaches break-even in three months.
A company with $2M in MRR, growing 5% month-over-month, and $1M in monthly burn has twelve months of runway but is default-dead. The growth rate doesn't support reaching break-even within the runway window.
Most investors — and most founders — will intuitively find the second company more comfortable to work with. More revenue, more runway, more "traction." The first company looks scary. But the second company is in serious trouble and the first is not.
The instinct to track runway rather than default-alive status is partly this: runway is observable, fixed, and doesn't require a model. Default-alive requires an assumption about future growth, which means making a specific bet. Founders avoid making that bet explicitly because making it explicit creates accountability.
The specific behavior I've seen in founders who manage this well is that they run the default-alive calculation monthly and treat it as the primary financial health metric — more important than runway, more important than total burn, more important than almost any other number.
The monthly cadence matters for a specific reason. The default-alive calculation is sensitive to the growth rate assumption, which is volatile. A company growing at 20% per month that hits three months at 8% per month is in a materially different position than the original projection suggested. Running the calculation monthly forces you to update the model with actual data rather than projections.
When the calculation shows the trend moving toward default-dead, you have three levers:
Reduce burn. The most direct lever, but also the most disruptive. Cutting burn means cutting headcount or infrastructure. The right time to do this is when the trend shows you're moving toward default-dead — not after you've crossed the line.
Accelerate revenue. Usually the harder lever, but the one founders prefer because it doesn't require contracting the team. The important caveat: growth rate is harder to change through effort than founders want to believe. Distribution advantages, product-market fit, and market timing drive growth more than founder effort does.
Raise capital. The lever most founders reach for first. The problem: if you're default-dead and you raise capital, you've bought time without solving the underlying problem. The next time the calculation comes due, you'll be in the same position — unless you used the capital to change one of the other levers.
The sequence that works is: achieve default-alive first, then raise capital to accelerate, not to survive.
I've watched founders make the same mistake I made at Realm, in the same way: treating capital raises as proof that the model works, rather than as working capital that extends the time window for proving the model.
The raise is not the validation. The raise is the obligation.
What the investors were buying when they funded Realm's Series B was a bet on a specific growth trajectory. If that trajectory held, we'd reach a position where the next round would be straightforward. If it didn't, we'd need to find a survivable path without the next round — and we hadn't built one.
Fundraising is optional, not a necessity. But this is only true if the company is designed from the beginning to survive without it.
Run the calculation. Monthly. Look at the number. The discomfort of seeing a bad answer early is much cheaper than the discomfort of seeing it too late to act.