Build · Create · Ops & Automation
Plan-B survival plan
A structured survival-plan document that names the fundraise (Plan A) assumption, the dated switch trigger, the specific cost-cut and revenue actions of Plan B, and the resulting runway, so the team has a written fallback instead of vague optimism.
You receive: A structured JSON survival-plan document validated against structural completeness and the buyer's frozen parameters.
Part of Choose Business Model
What you receive
The shape of your delivered file. Your result is generated for your inputs.
Your deliverable is a structured document carrying these fields:
- Action
- Assumption
- Cost cuts
- Expected monthly revenue usd
- Fundraise target usd
- Monthly savings usd
- Plan a
- Plan b
- Projected monthly net burn
- Resulting runway months
- Revenue actions
- Switch trigger
- Trigger condition
- Trigger date
Opens soon
STUD opens runs for everyone soon, on every play at once.
Scope of the check
What's verified: STUD verifies the plan is structurally complete: a dated, on-time switch trigger, the required counts of distinct cut and revenue actions, a stated Plan-B runway that meets the floor and is arithmetically consistent with cash/burn. Each cost cut and revenue action must be an object, not a plain string: a cost cut is {action: a non-empty name, monthly_savings_usd: a number of 0 or more}, and a revenue action is {action: a non-empty name, expected_monthly_revenue_usd: a number of 0 or more}. This play's scope is Plan A as a fundraise: plan_a names a fundraise assumption, a fundraise_target_usd greater than zero, and the date you expect that raise to close (a Plan A that is not a raise is out of scope for this play). It does NOT verify the cost cuts are actually achievable, the revenue actions will materialize, or that the company will in fact survive. It checks the plan exists and is internally coherent, not that it will work.
Get early access to STUD the day it goes live.