Scenario records for Bootstrapped SaaS companies. Illustrative framework analysis — not determinations for any specific organization.
Bootstrapped SaaS companies have a structural advantage in Bitcoin treasury decisions that venture-backed companies do not: decision authority is complete and concentrated. A founder who owns the company can decide to allocate Bitcoin to the corporate treasury without board authorization, investor consent, or governance committee approval. The constraint the framework identifies is converting that informal authority into a documented treasury policy — a written record that survives the founder's absence and can withstand review by a banker, accountant, or future investor.
The most common failure mode in bootstrapped SaaS Bitcoin treasury decisions is treating a founder's decision as equivalent to a treasury policy. A founder who buys Bitcoin for the company treasury has not created a Bitcoin treasury policy. The framework requires a written policy covering allocation limits, volatility thresholds, custody procedures, and liquidation conditions. Without this documentation, a Bitcoin treasury position has no governance record — creating risk in banking relationships, accounting treatment, and succession planning.
Key-person custody risk is a structural condition the framework identifies in this company type. When the founder holds the Bitcoin treasury position without documented custody procedures and succession authority, the company has created a continuity problem. If the founder becomes unavailable — through illness, accident, or business transition — who has authority to act on the Bitcoin position? The answer must exist in writing. Bitcoin's custody mechanics make undocumented key-person risk more consequential than equivalent undocumented risk in traditional treasury assets.
Common Constraint Patterns
Treasury Policy Gap
Observed across a large majority of bootstrapped SaaS scenarios. This condition arises from founder-controlled governance structures where treasury management is operationally driven rather than policy-driven. The conclusion most commonly shifts when a written treasury policy is formalized — not when reserve size increases.
Undefined Volatility Threshold
Frequently observed in this company type. The framework requires a documented volatility tolerance threshold — a defined maximum drawdown or allocation percentage that triggers a review. This condition arises from the absence of formal treasury governance infrastructure in founder-controlled organizations.
Key-Person Custody Risk
Commonly present in bootstrapped SaaS scenarios. This condition arises when custody authority and treasury knowledge are held by a single individual without documented succession procedures. The documentation requirement is procedural, not technical — it specifies who would act, under what authority, with access to what information.
Reserve Tier Patterns
At $500K–$1M, the framework identifies both financial constraints and governance documentation as typically marginal. Reserve levels limit allocation buffer, and the documentation baseline is usually absent. At $5M–$10M, financial capacity clears but governance documentation remains the binding condition. At $25M and above, the framework identifies the continued absence of formal governance infrastructure as a signal — the analysis expects more durable policy structures at higher reserve levels, and their absence is itself a condition the framework identifies.
Framework Questions
What governance conditions apply to Bitcoin treasury allocation in a founder-controlled bootstrapped SaaS company?
▸
The framework requires that founder authority be documented in a written treasury policy covering alternative assets, with defined volatility thresholds and custody continuity procedures. Authority is not evaluated as absent — the condition is whether authority has been converted into a durable written record that the framework can evaluate.
What governance documents does the framework require for a bootstrapped SaaS company to proceed?
▸
The framework requires at minimum: a written treasury policy explicitly covering Bitcoin allocation, a defined volatility tolerance threshold, custody procedure documentation, and a continuity plan identifying who has access authority if the founding decision-maker is unavailable. These documents establish the governance record the framework evaluates.
How does the framework evaluate allocation size relative to governance documentation requirements?
▸
Allocation percentage does not reduce governance documentation requirements. The framework requires the same treasury policy, the same volatility threshold documentation, and the same custody continuity plan regardless of whether the allocation is 1% or 10%. Financial constraint evaluation changes with allocation size; governance requirements do not.
How does the framework evaluate custody continuity risk in a bootstrapped SaaS company?
▸
The framework identifies custody continuity as an operational condition requiring documentation when treasury knowledge and access are concentrated in one person. The requirement is not technical — it does not require multisig or a custody service. The framework requires a written procedure identifying successor access, credential location, and authorization authority.
Representative scenarios for this company type are available in the Scenario Atlas, where these conditions are evaluated under predefined assumption sets across all reserve tiers and decision positions.
Translate