Build · Create · Writing & Content
Workflow lock-in and switching-cost register
The founder gets a structured lock-in register that documents, per top customer, the automations / integrations / team-workflows running through the product plus a switching-cost estimate and an integration-depth tier, surfacing where the product is embedded and where it needs to go deeper.
You receive: A JSON object: { customers: [{ customerId, name, automations: [string], integrationsDependedOn: [string], teamWorkflows: [string], integrationDepth: enum(surface|moderate|deep), switchingCostEstimate: enum(low|medium|high) }], depthCounts: { surface, moderate, deep }, surfaceCustomers: [customerId...] }
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:
- Automations
- Customer Id
- Customers
- Depth Counts
- Integration Depth
- Integrations Depended On
- Name
- Surface Customers
- Switching Cost Estimate
- Team Workflows
Some fields carry set values, drawn from:
automations, integrationsDependedOn, teamWorkflows
low, medium, high
surface, moderate, deep
yes, true, y, 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 consistent: minimum customer count, each customer carrying a depth + switching-cost rating with at least one lock-in signal, 'deep' ratings backed by the required integration count, and the tallies/surface-list matching the data. STUD does NOT verify the switching-cost estimates are accurate, that the listed automations exist, or that the lock-in is real. It checks the audit's structural completeness, not the truth of the stickiness.
Get early access to STUD the day it goes live.