Case study

Runway

A cash-runway calculator built around one question: are you default alive or default dead, and how much time do you actually have.

Role: Design and build, solo

Stack: Next.js, TypeScript, Zustand, Supabase, Vitest

Runway's public landing page, with the pitch: how long until the money runs out, and what actually changes it

Why it exists

The problem this was built to solve, and the approach behind it.

Before · the problem

Cash-runway math usually lives in a spreadsheet that goes stale the moment a real decision needs to be modeled against it.

After · the approach

Runway runs the plan through a small deterministic projection engine.

A hire, a raise, a cost change, none of it replayed against the actual projection

Timeline events run through the same model as starting cash, burn, and revenue

Founders end up estimating from an average burn rate instead of a real number

A month-by-month cash curve gives an actual number, not an average

No way to see how one decision actually moves the cash-out date

A real cash-out date and a default-alive verdict, kept current as assumptions change

What it does

A public landing page paired with a focused planning app for modeling runway scenarios
Month-by-month cash projection from starting cash, itemized burn, and revenue
Timeline events, a hire, a raise, a cost change, replayed against the projection instead of a flat average
A default-alive or default-dead verdict, not just a runway number
Plain-English insights derived from the same engine: burn sensitivity, what a raise actually buys
A ledger view with month-by-month detail and CSV export
Versioned state, so a saved plan survives a schema change

In the product

Swipe or click through a few screens from the working app.

The Plans page in Runway, showing saved plans side by side for comparison

The Ledger page in Runway, with runway totals at a glance and a full month-by-month projection table, including a CSV export

The Plan page in Runway, with cash and cost inputs on the left and a live chart showing cash on hand, the cash-out date, and a default-alive or default-dead verdict on the right

Architecture decisions

The calls that shaped the build, written the same way the product itself records them.

Pure math, no framework in the projection

The month-by-month projection, the default-alive check, and the insight generation all run outside React, deterministic and framework-free. The chart, the ledger, and the verdict all read from the same engine output, so they cannot disagree with each other.

Founder view and operator view, kept apart

Founder-facing assumptions live in one store. Instance defaults, feature flags, and demo data live in a separate operator surface. Mixing the two is how a planning tool quietly turns into an admin panel with a spreadsheet bolted on.

Diagnostics that check the engine against itself

Beyond the unit tests, the app runs live invariant checks against its own projection engine: results stay deterministic, cash decays monotonically, a raise extends the runway and a hire shortens it. A bad assumption shows up as a failed check instead of a verdict nobody double-checked.

Want something built with this kind of judgment?

A focused 30-minute call to scope the work and see if it is a fit. No pitch.