SAKIZLI AI
Article18 Sept 2026 · 37 min read36 / 38Members · Subscription

Worst case first

Plan financial viability, runway, and failure scenarios

RunwayLiquidityProject economicsResilience
FFurkan SakızlıAI researcher & tutor · independent
Five frosted tiles growing smaller toward the right, joined into a chain; the fifth is solid blue, a dark bar with an amber dot stands just behind it, and the line continues only as a dashed one, while a path branches down from the blue tile to two smaller alternative tiles
The bar sits before zero, not on it – and the branch downward is prepared before the line turns dashed
Image generated with AI

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:

CategoryMeaningSafe liquidity?
UnrestrictedIn the account or callable quickly without restrictionsYes
RestrictedGrant or budget with a defined useOnly for that use
Contractually dueLegally committed but not yet receivedSubject to timing and default risk
Expected / negotiatedPipeline, letter of intent, possible financeNo

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:

MonthOpeningsecure receiptsdue paymentsEnding
1180,00030,00045,000165,000
2165,00015,00050,000130,000
3130,00010,00055,00085,000
485,000060,00025,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:

ScenarioPurposeTypical assumption
BaseRealistic operating planAssumptions with the strongest current evidence
DownsideWorse but clearly plausibleslower sales, later payment, higher review cost
Severe but plausibleTest survival and orderly responseseveral 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 axisDownside question
DemandWhat if fewer qualified customers convert?
TimeWhat if pilot, integration, or approval takes twice as long?
PaymentWhat if invoices arrive 30–60 days late?
UsageWhat if token, storage, or tool consumption per case rises?
QualityWhat if human review, rework, or support expands?
DependencyWhat if provider, API, model, or data source fails or costs more?
Law / approvalWhat 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:

ReserveCoversMust not become
Operating liquidity reservepayment volatility and short interruptionsa permanent business model
Risk reserveidentified cost uncertaintyhidden scope budget
Management reserveunknown project-wide events with approvalfreely 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 → Subscribe

0 comments

Loading comments…

Sign in to comment · become a member →