Build · Create · Ops & Automation
Build a 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'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. 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.
Opens soon
This objective is verified and ready. It opens soon, once sign-in and payments are live.
Deliverable interface
The exact vocabulary the automated check enforces: keys, tokens, entry points, and worked examples. Generated from the verification source.
{
"buyerParamKeys": [
"current_cash",
"plan_a_close_date",
"required_postcut_runway_months"
],
"checkNames": [
"format_parses",
"plan_a_present",
"switch_trigger_dated",
"cut_actions_count",
"revenue_actions_count",
"runway_met",
"arithmetic_consistency",
"dedup"
],
"constants": {
"_ISO_DATE_RE": "^\\d{4}-\\d{2}-\\d{2}$"
},
"deliverableLabel": "plan_b_survival_plan",
"documentKeys": [
"assumption",
"cost_cuts",
"fundraise_target_usd",
"plan_a",
"plan_b",
"projected_monthly_net_burn",
"resulting_runway_months",
"revenue_actions",
"switch_trigger",
"trigger_condition",
"trigger_date"
],
"enumLiterals": [],
"submission": "a JSON document (submitted as a string), validated as data; every check below must pass",
"tier": "doc-validator"
}Get early access to STUD the day it goes live.