Time to Capacity Limit
Definition
Months of system capacity remaining at the current growth rate before the platform requires major (not incremental) infrastructure investment — typically driven by the binding bottleneck (database, message bus, single-tenant compute ceiling, regional capacity, or compliance-driven re-architecture). Surfaces the "scale runway" alongside the financial runway. Common pitfall: a single number hides which bottleneck binds. Boards should require the bottleneck to be named ("database shard hot-spot binds at ~150K accounts at current growth, ~4 months out"), not just the headline months — a named bottleneck makes the investment decision concrete.
Why it matters
Sequences major infrastructure work against revenue growth. A 6-month scalability headroom against a 9-month financial runway is a foreseeable crisis the board should be addressing now. Pairs naturally with `defensive_roadmap_pct` (which funds the work).
How it's calculated
Engineering-attested estimate: months_until_binding_bottleneck_at_current_growth_rate. Recompute when growth-rate assumption changes or when capacity work lands. Always surface the binding bottleneck name alongside the months number — `12 months (database write throughput)` not just `12`. How to interpret it
Industry folk-wisdom, not citation-grade: 12+ months of headroom is comfortable; 6–12 months means the rearchitecture project should be in flight; under 6 months means the project is critical-path and may already be late. Compare against `finance.runway_months` — financial runway shorter than scalability headroom means the company will hit the cash wall first; the inverse means the company will hit the scale wall first and should be planning the rearchitecture into the current operating plan.
Source
imboard Editorial
Benchmarks
| 25th percentile | Median | 75th percentile |
|---|---|---|
| 4 | 9 | 18 |
Higher is better. Source: imboard Editorial (2026).
Stage relevance
Typically owned by
Related KPIs
Percentage of the planned roadmap allocated to defensive work — platform reliability, security/compliance, scalability rearchitecture, table-stakes parity with competitors, customer-retention features. The complement of `offensive_roadmap_pct`. Common pitfall: defensive work is chronically under-funded (less visible to customers, harder to demo) until a quality-churn or scalability event forces a reactive surge. Boards should treat sustained zero or near-zero defensive allocation in a maturing product as a leading indicator of future quality issues — per the standard product-management argument (Marty Cagan and similar product-leadership writing), a healthy roadmap pays both growth and platform-health rent.
Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. `innovation_capacity_pct` which is a single percentage for new-capabilities work, and vs. `offensive_roadmap_pct` which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly.
Percentage of customer churn (logo or ARR, define explicitly) where the primary stated reason is product or quality problems — bugs, performance, missing core functionality, reliability incidents. Distinguishes product-driven churn from pricing-driven, competitor-driven, or use-case-fit-driven churn. Common pitfall: relying on free-text exit-survey reasons. Customers commonly cite "price" when the underlying issue was reliability or missing features — boards should require both the customer-stated reason and the CSM/Account-Manager-assigned root cause, and watch the gap. The Pendo "Product-Led Growth Benchmark" and similar product-analytics publishers cover product-driven churn qualitatively, not as published numeric ranges.
Estimated number of months the company can operate at the current net burn before unrestricted cash reaches zero, holding everything else constant. The single most consequential survival input for venture-backed companies — it sets the urgency of every fundraising, hiring, and cost decision. Common pitfall: runway is often quoted off `finance.total_cash_in_bank` and a single-month spot-burn instead of operationally-available cash and a 3-month-trailing burn — the result is a runway that looks 2–4 months longer than it actually is when working capital tightens. Boards should ask which cash and which burn went into the calculation.
Year-over-year percentage growth in ARR (or recognized revenue, if explicitly anchored) — comparing the current period to the equivalent period 12 months prior. The single most-watched investor metric and the largest single driver of SaaS valuation multiples. Common pitfall: comparing to the prior quarter (QoQ) and reporting it as "growth rate" — boards and investors mean YoY unless explicitly noted otherwise. Anchored to KBCM/Sapphire SaaS Survey 2024 §YoY ARR Growth for cross-company benchmarking.
Track these KPIs with your board
I'mBoard helps startup CEOs report the metrics that matter, track resolutions, and run better board meetings.