Build · Create · Ops & Automation
Founder operational load and delegation register
The founder gets a structured operational-load register that classifies every routed task by delegation tier and flags the ones that stall in a founder's week-long absence, turning 'I do everything' into a triaged plan for what to systematize, delegate, or keep.
You receive: A JSON object: { items: [{ itemId, name, itemType: enum(task|decision|approval), frequency: enum(daily|weekly|monthly|adhoc), disposition: enum(automate|delegate_non_founder|founder_only), stallsInWeekAway: bool, reason } ], counts: { automate, delegate_non_founder, founder_only }, busFactorRisks: [itemId...] }
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:
- Automate
- Bus Factor Risks
- Counts
- Delegate non founder
- Disposition
- Founder only
- Frequency
- Item Id
- Item Type
- Items
- Name
- Reason
- Stalls In Week Away
Some fields carry set values, drawn from:
automate, delegate_non_founder, founder_only
daily, weekly, monthly, adhoc
task, decision, approval
yes, true, 1
Opens soon
STUD opens runs for everyone soon, on every play at once.
Scope of the check
What's verified: STUD verifies the register is complete and internally consistent: minimum item count, every item dispositioned and stall-flagged, tallies match the items, and the bus-factor list matches the stall flags. STUD does NOT judge whether a task is correctly classified as automatable vs founder-only, or whether it would truly stall in a week. It checks the inventory's structural completeness and arithmetic, not the founder's classification judgment.
Get early access to STUD the day it goes live.