:
October 28, 2026
.png)
It's late October. Sarah's spreadsheet, last updated in July, says fourteen months of runway. She has been quoting that number to advisors and to herself. Then the bookkeeper's September report lands: two part-time contractors converted to full-time in August, the cloud bill doubled when usage grew, and a large customer paid late. Runway is seven months, not fourteen. Nothing about the business changed in October; only Sarah’s knowledge of it did, and the three months she spent believing she had fourteen months were three months she could have spent extending her runway. Now her timeline is tight, will she be able to complete a fundraise in 7 months? Or will she need to reduce headcount to buy herself enough time?
This is how most startups actually die. Not from a competitor or a bad product, but from running out of cash while the founder was looking at something else. Kirsty Nathoo, Y Combinator's longtime CFO and now Partner Emerita, helped over 2,000 companies through the program, and in her talk on managing startup finances she is blunt about it: the metric that matters above all others is cash. How much you have, how much is moving in and out, and therefore how much time you have left. If you're an early-stage founder, watch it.
What stands out about her list of mistakes is that the first three mistakes aren't about bad judgment. They are about missing information. Missing information is a systems problem, which means it has a systems fix.
Kirsty's baseline is almost embarrassingly simple: bank balance, money in, money out. From those you derive burn (out minus in), runway (balance over average burn), and growth rate. Then the question that ties them together: are you default alive? If expenses stayed flat and growth continued, would you reach profitability before the cash runs out?
Everything here comes from bank statements. Yet when YC partners ask founders these questions in office hours, a striking number can't answer. Don’t be one of them.
The ones who do calculate runway tend to do it once, feel reassured, and move on. Kirsty's rule is weekly at minimum, daily when runway is short or revenue is choppy. She also warns against rounding in your own favor: call a $15K burn $10K and you've bought five imaginary months and zero real ones. You run out of money on the same day, with less warning.
The default-alive test assumes constant expenses. Real expenses climb, and Kirsty names three places founders systematically underestimate: their own unpaid labor, which hides the true cost of acquiring customers; fully loaded headcount, where benefits, equipment, and taxes push the real cost 25 to 50 percent above salary; and customer acquisition itself, which gets more expensive as the motivated early adopters run out. Projecting burn means forecasting what it will become, not rolling today's figure forward.
All three failures share a root cause. Stale, static data that nobody is updating. The general ledger was designed as a record of what already happened, assembled by people, delivered in monthly or quarterly batches. A founder asking "how much runway do I have right now" is asking a present-tense question of a past-tense system. T:0 closes the gap at the source. It connects to your banks, cards, payroll, and billing, classifies every transaction as it lands, and derives the books continuously from what is actually happening. The same substrate that makes the accounting correct is what makes Kirsty's three numbers impossible to lose track of.
Time has changed and the static monthly updates are a thing of the past. Modern financial software is deeply interconnected. Mostly driven by the work Plaid and the Open banking movement did throughout the 2010s. Now your journal entries are derived from live money movement; bank balances, inflows, and outflows are current by definition. Burn, runway, growth rate, and default-alive status are computed and recomputed in real time using real data, not by you on a Sunday night before an important investor meeting. Lumpy months are handled the way Kirsty recommends: a trailing average alongside the raw figure, so one large legal bill doesn't distort the picture. The most impactful modern ERPs are taking this one step farther and explaining what is driving the numbers, and if you don’t like the numbers, how to change them.
In our example from above Sarah decides 7 months of runway is too little. Fundraising takes at least 6 months and she doesn’t want to be desperate going into the raise. So she has to make a change
There is no export-and-update ritual to find out where you stand so the numbers are as fresh at 9am Tuesday as the moment you last looked. Ask The CFO what happened this month and the answer is built from every transaction. Log-in to the T:0 app or get a quick summary sent to you where you already work, in Slack or via email. Always know your numbers, even in the thick of building.
Scenario analysis in T:0 begins with your actual history: not a guess at what infrastructure costs were seven months ago, but what they actually were. From that base you change the assumptions Kirsty says founders get wrong. Add a planned hire and the model includes the fully loaded cost, not a single line increase. Set an acquisition-cost trajectory and watch runway recalculate. Run a pessimistic case beside your base case so the number you plan against is the one that can actually kill you. Slice burn by week or month, annualize it, compare spend patterns. All of it sits on top of real data rather than a blank grid you’re building form zero.
Runway isn't a number for the deck or for comparing yourself to other founders. It exists so you don't lie to yourself. Most companies that die from running out of cash didn't have to. They just weren't looking, or they were looking at something stale. T:0 exists so that looking is automatic and the number is never stale. The ledger you already need for your books becomes the instrument you run the company by. Get started with T:0.
.avif)
