Why I built it
I wanted a planning tool that never asked me to trust a number. Most spreadsheets and planning apps show you a runway figure and leave you to take it on faith, and a formula buried in a cell reference is not much better once a model gets complicated. I wanted every figure to be able to show its own working — the formula, the inputs, the engine version that produced it — the same way you would want a calculator to show its steps, not just its answer.
The money handling grew out of the same instinct. A monthly growth rate compounded over years is exactly where an ordinary floating-point calculation quietly drifts from the truth, and that kind of drift is very hard to trace back once it shows up as a reconciliation that does not quite add up. So amounts are held as exact whole units and rates as exact fractions, and rounding happens once, at a named point, rather than a little at a time throughout a calculation.
How it works
You model your business as revenue streams, expense lines, payroll, funding and debt. The engine runs those through a fixed order — revenue and payroll first, since expenses that scale with revenue need something to scale against — and produces cash flow, burn, runway and a break-even estimate. Runway specifically is not a single division: cash is walked forward one month at a time until it crosses a floor you set, because a plan that is not flat month to month gets the wrong answer from a simple divide.
Every input you enter is classified as one of three things: an actual (something that already happened), an assumption (something you are supplying as a planning input), or a calculation (something the engine derived). That classification is visible wherever a figure appears, so a projected number never looks like a fact, and a fact never looks like a guess.
Because the same calculation engine runs in the browser for an anonymous visitor as would run for a signed-in one, signing up later is meant to add saving and syncing rather than change how anything is calculated. History does not move once written: past calculation snapshots stay as they were, and a later change to the engine is recorded as the engine changing, never as quietly rewriting what an earlier figure said.
For developers: provenance and the state the first release shipped in
A calculated value literally cannot be constructed in the codebase without a provenance record attached — a stable method name, the formula in human-readable form, the exact set of inputs that fed it, and the engine version. That is the concrete mechanism behind keeping AI out of the calculation path: there is no route by which an AI-generated number could enter a plan as a calculated figure, because doing so requires machinery a model call does not have access to. A calculation's identity is derived from a hash of its method, scenario, period and sorted input references, deliberately excluding the time it ran, so re-running an unchanged calculation produces the same identity rather than a new one each time.
The most serious problem found during the build was not in this arithmetic at all — the financial engine's golden test models were correct throughout and were never the issue. Shortly after the first production release, a first-time visitor was shown a fully worked example plan, complete with a cash balance, a burn rate and a break-even date, and nothing on screen said it was not theirs. It had been added deliberately, on the reasoning that an empty planning grid tells a new visitor nothing about what the product does. That reasoning did not justify showing fabricated figures indistinguishable from a real financial position, and more than two thousand passing tests had not caught it, because every one of them started from the premise of an already-built plan and none asked what a visitor who had entered nothing should see.
The fix made the state explicit rather than inferred: a plan is now either genuinely empty, an example that was explicitly chosen and permanently labelled as such, or a plan the user actually built, and a dedicated test suite now runs from a completely clean browser with no fixtures at all, checking specifically that a fresh visit never shows a calculated figure the visitor did not ask for. Two more defects surfaced on the deployed site that no unit test had reached, because both tests mocked the exact browser behaviour that was broken — a backup export that had never once produced a working file, and a download that never completed because its cleanup ran before the browser had read the data.
Where it may go
Next: finish wiring the fuller risk and goal-tracking checks into the Risks and Goals screens, which today run a smaller, temporary set of checks directly against a plan's results rather than the complete rule set the engine is designed to support.
Later, if there is real demand for it, multi-currency modelling is a plausible direction, but it needs a proper exchange-rate model with its own provenance and as-at dates behind it, and I would rather leave it out than bolt on a conversion that cannot be traced the way everything else in the plan can.