Worst case first
Plan financial viability, runway, and failure scenarios

An AI project can be strategically plausible, technically impressive, and profitable on paper — and still die. Not because value is absent, but because cash runs out before proof arrives. Invoices are paid later than expected. Cloud, review, and integration costs rise together. A financing conversation is mistaken for available money. Or the team discusses stopping only after almost every real option has disappeared.
That is why the worst case does not belong at the end of a business plan. It belongs at the beginning of operational financial control.
Worst-case planning is not pessimism. It translates uncertainty into time, thresholds, and prepared decisions.
A good idea can fail on the wrong timeline
General project economics asks whether an offer can create value at all: audience, problem, willingness to pay, price, variable cost, and contribution margin. That work is necessary. It does not yet show whether the project can finance the journey to a viable state.
Between today and that state are months of payroll, development, data work, legal review, sales, and operations. Revenue often arrives after the work. This timing gap is the subject of this article.
The boundary from general project economics
This text does not repeat market segmentation, pricing, or unit economics. It assumes them and asks a different question:
What happens when central assumptions arrive later, cost more, or perform worse than planned?
The answer is not a second optimistic forecast. It is a survival system made of a cash calendar, scenarios, leading indicators, reserves, financing deadlines, and pre-agreed actions.
Profit is not liquidity
A company may look profitable for a period and still become unable to pay. Revenue may be recognized while the money has not reached the bank. Investments can be paid immediately although their benefit appears over years. Taxes, payroll, and suppliers follow their own due dates.
The UK Insolvency Service explicitly notes that insufficient ready cash can be a major cause of failure even where a company trades effectively.[2] Project control must therefore ask not only whether a contract earns money, but whether every obligation can be paid when due.
A budget is not cash flow
A budget assigns planned income and expenditure to categories. A cash-flow plan assigns actual receipts and payments to dates. The two views may diverge sharply.
An annual budget can balance while a funding gap appears in month four. An invoice for 60,000 euros does not fund payroll if it is paid 60 days later. A robust downside plan therefore needs at least a monthly view and, in critical phases, a weekly one.
The cash calendar is the operational truth
The calendar begins with cash that is actually available and unrestricted. Payments are entered on realistic dates: not when an invoice is issued, but when it is likely to be paid.
It separates four kinds of money:
| Category | Meaning | Safe liquidity? |
|---|---|---|
| Unrestricted | In the account or callable quickly without restrictions | Yes |
| Restricted | Grant or budget with a defined use | Only for that use |
| Contractually due | Legally committed but not yet received | Subject to timing and default risk |
| Expected / negotiated | Pipeline, letter of intent, possible finance | No |
The most common planning error sits in the last row: hope silently becomes cash.
Burn rate: how quickly does the project consume cash?
Gross burn is all cash expenditure in a period. Net burn subtracts reliable cash receipts in the same period.
Net burn = cash expenditure − reliable cash receipts
The distinction matters. A growing project may have high spending and high receipts. The danger is not gross burn alone, but its combination with uncertain receipts and irreversible commitments.
Runway: not a comfort number, but a decision deadline
With a constant positive net burn, a first approximation is:
Runway = unrestricted available cash ÷ net burn per period
If 120,000 euros is unrestricted and net burn is 20,000 euros per month, the static result is six months. This is an illustration, not a benchmark. It is also no guarantee: variable cost, payment delay, tax, or stepwise infrastructure spending may shorten the true window.
Why the static runway formula often misleads
The formula assumes a flat path. Real projects have ramps, annual bills, milestone payments, minimum purchases, notice periods, and seasonal income. An average can hide an early deficit.
The better question is: In which week or month does unrestricted cash fall below a defined safety floor?
Dynamic runway uses payment sequences
A dynamic view rolls every period forward:
Ending cash(t) = opening cash(t) + secure receipts(t) − due payments(t)
Ending cash becomes the next period’s opening cash. Expected but unsecured income stays in a separate scenario line. The team sees not only how many months remain in theory, but when each gap appears.
The table also needs a safety floor above zero. Zero cash is a poor trigger because payroll, refunds, cancellations, or an orderly close may already be unaffordable by then. The floor depends on real residual duties: notice periods, open customer work, data migration, tax payments, and minimum operations. It is therefore a justified project value, not a universal number of months.
A purely illustrative example shows the logic. The amounts are not a recommendation:
| Month | Opening | secure receipts | due payments | Ending |
|---|---|---|---|---|
| 1 | 180,000 | 30,000 | 45,000 | 165,000 |
| 2 | 165,000 | 15,000 | 50,000 | 130,000 |
| 3 | 130,000 | 10,000 | 55,000 | 85,000 |
| 4 | 85,000 | 0 | 60,000 | 25,000 |
With a justified safety floor of 40,000, it is breached in month four. The operational trigger comes earlier — even though cash is still present.
Three scenarios are the minimum, not the ambition
A single forecast is a story. Early projects need at least three coherent scenarios:
| Scenario | Purpose | Typical assumption |
|---|---|---|
| Base | Realistic operating plan | Assumptions with the strongest current evidence |
| Downside | Worse but clearly plausible | slower sales, later payment, higher review cost |
| Severe but plausible | Test survival and orderly response | several coupled pressures at once |
A worst case is not the end of the world. It is the hardest case still plausible enough to change the decision.
The three cases must not force the same decision. The base case shows which evidence permits the next expansion stage. The downside case shows when spending or scope changes. The severe-but-plausible case tests whether pausing, pivoting, or closing remains practical and financeable. If all three merely say “continue,” the team has built three versions of the same hope.
Scenarios must be internally consistent
A downside case cannot merely reduce revenue by 30 percent while keeping everything else fixed. Lower demand may mean longer sales cycles, higher acquisition cost, and deeper discounts. Quality problems may increase support, refunds, and review effort at the same time.
Each scenario needs a causal account: what changes first, what follows, and which receipts or costs move as a result?
Coupled shocks are more dangerous than isolated deviations
Many plans stress one variable at a time. Crises couple them. A provider raises prices while a new model consumes more tokens. A customer delays acceptance because quality review takes longer. Burn rises as the expected receipt disappears.
Stress testing should therefore include at least one combined case. The point is to see whether the same reserve is being asked to cover several consequences of one disturbance.
The seven financial stress axes of an AI project
| Stress axis | Downside question |
|---|---|
| Demand | What if fewer qualified customers convert? |
| Time | What if pilot, integration, or approval takes twice as long? |
| Payment | What if invoices arrive 30–60 days late? |
| Usage | What if token, storage, or tool consumption per case rises? |
| Quality | What if human review, rework, or support expands? |
| Dependency | What if provider, API, model, or data source fails or costs more? |
| Law / approval | What if review, licensing, or procurement delays launch? |
These axes must not become arbitrary percentages. Each needs a mechanism and evidence.
The pre-mortem: imagine the failure has already happened
In a pre-mortem, the team assumes that the project failed twelve months from now. Each person answers independently: What probably happened?
Research by Deborah Mitchell, Jay Russo, and Nancy Pennington on “prospective hindsight” found that imagining an outcome as already having occurred can improve people’s ability to generate reasons for it.[5] In projects this moves the conversation from “Could it happen?” to “How did it happen?”
A pre-mortem is not a risk list with dramatic language
A useful entry contains five elements: an observable trigger, the affected assumption, the financial transmission, the earliest signal, and the prepared response.
“The market collapses” is too broad. “Qualified discovery calls stay below four for three months, moving the first paid cohort by eight weeks and increasing net burn by X” can be managed.
Reference Class Forecasting corrects the inside view
Teams often plan from the inside: decompose their own project and estimate each step. That tends to underweight unknown difficulties and overstate how exceptional the case is.
Reference Class Forecasting adds the outside view. Find a class of actually comparable projects, observe their distributions of duration, cost, and outcome, and locate the current project within them. Bent Flyvbjerg describes it as a method for curbing optimism bias and strategic misrepresentation.[4]
A reference class must truly be comparable
“Other AI start-ups” is usually too broad. Better classes may be B2B pilots with similar procurement, sensitive-data projects, human-review products, or integrations into the same system class.
Even a small class is better than intuition alone if its limits are disclosed. It does not create certainty, but provides an empirical base for buffers and timing.
Cost uncertainty belongs in the estimate, not a footnote
The U.S. Government Accountability Office’s Cost Estimating and Assessment Guide treats risk and uncertainty analysis as part of a credible estimate.[1] A single point number hides the range of possible outcomes.
In an AI project, cost blocks therefore need drivers, ranges, and dependencies. A reserve is derived from identified uncertainty rather than added by feel.
Not every reserve is the same
At least three pools should remain separate:
| Reserve | Covers | Must not become |
|---|---|---|
| Operating liquidity reserve | payment volatility and short interruptions | a permanent business model |
| Risk reserve | identified cost uncertainty | hidden scope budget |
| Management reserve | unknown project-wide events with approval | freely spendable team cash |
Mixing these pools makes the plan look comfortable while real room to act shrinks.
Separate reversible and irreversible commitments
Not every euro has the same flexibility. Monthly tools, timeboxed freelance packages, and incremental cloud capacity are easier to change than leases, minimum purchases, permanent roles, or large prepayments.
The downside plan records for every expense: cancellable until when, with what notice, at what exit cost, and with what loss of capability.
The commitment calendar reveals the last good decision point
Every major commitment has a date when it can still be prevented or reduced. That date may come long before payment.
If an annual contract begins in June but cancellation is due in April, April is the operational decision point. A project that only watches the bank balance discovers it too late.
Financing promises are not cash
An investor conversation, grant application, or verbally confirmed order must not extend base runway. Only a credible, legally effective, and realistically timed commitment may enter a scenario, with its remaining risk visible.
This does not protect against hope. It protects against treating hope as a paid invoice.
The financing deadline comes before zero
New finance takes research, documents, review, negotiation, decision, and payment.[3] The key deadline is therefore not “When is the account empty?” but:
Financing start = safety threshold − realistic financing lead time − decision reserve
● Members only
Read the full article and download all files with a membership.
Unlock full article + downloads → Subscribe0 comments
● Loading comments…