Runway Warning

A business can be profitable and still have too little cash on payday. A balance snapshot or a generic months-of-runway number hides the timing between customer payments, regular bills, and payroll. Owners need a warning while there is still time to respond, with enough context to act.

Four problems shaped the build

Timing is hard to see: Invoices may arrive after payroll, even when a business expects to earn enough overall.

A forecast can hide weak inputs: Stale bank data, missing rows, a balance that does not reconcile, or payroll that has never appeared in the records can make a confident answer misleading.

A warning without a next step leaves the owner stuck: A risk label alone does not say which invoice to follow up, which payment could move, or how much cash would close the gap.

A demo can look more certain than the product is: Generated histories can illustrate different states, but they cannot establish forecast accuracy for real businesses.

A warning that earns trust before it asks for action

An operator imports bank transactions and invoices, enters a current balance, and configures payroll, recurring spending, one-off payments, and a cash cushion. The product checks history length and freshness, transaction gaps and balances, whether payroll appears in the data, and whether invoice activity agrees with bank deposits. A failed check withholds the forecast and explains what to fix.

When the records support an answer, the forecast looks 13 weeks ahead. It resamples ordinary cash in and out from recent history, includes scheduled payroll and recurring payments, and models invoice collection timing. Payday risk is expressed as a natural count such as ‘7 in 10 chance,’ not a percentage. A follow-up action is evaluated against the same simulated futures so the owner can compare the effect of collecting invoices, moving an eligible one-off payment, or adding cash.

A weekly track record checks how earlier forecasts matched later balances. The operator can review each business, while an owner receives a read-only report link and, when configured, a warning email. The demo seeds three fictional businesses to show an at-risk warning, a case where data is too weak to answer, and a covered case.

The MVP connects a React and TypeScript workspace to a Python and FastAPI service, SQLAlchemy and SQLite persistence, CSV import flows, the cashflow simulation, forecast checks, suggested levers, weekly scheduling, and owner-facing reports. The central product decision is to pair each warning with its assumptions and a possible next action, while making ‘can't tell yet’ a useful result when the evidence falls short.

The supplied screens show fictional demo businesses and generated balances. Their example statuses and figures are illustrative only. Project documentation records checks against generated demos and hand-written CSV fixtures shaped like common bank, QuickBooks Online, and Xero exports; it also states that no real bank export, invoice list, or business has been tested. There are no measured customer results, forecast-accuracy claims, or time-saved figures.

The forecast needs further validation before real-business use. The documented backtest compares overlapping weekly forecasts as if they were independent, which can withhold answers too often. The current model also covers one bank account, omits bank holidays and seasonality, and assumes a planned invoice collection pays in full by the suggested date. The project has no live accounting or bank-feed connections, production hosting, or backup service.

The next evidence milestone is to run the import and forecast workflow on several real businesses, record where data checks refuse an answer, and examine forecast coverage. After that, the backtest can be improved and the model can address multiple accounts, holidays, and seasonal history.