I'mBoard API Docs

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. — Product KPI, I'mBoard-authored (editorial tier).

I'mBoard-authored (editorial tier)

No public third-party standard anchors this KPI yet, so I'mBoard authors and maintains the definition — transparently labeled as editorial tier. See the ontology methodology for the published vs editorial tier system and the back-attribution workstream.

Rogue ID: product.scalability_headroom Type: Number (months) Domain: Product

Definition

Formula

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`.

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 to interpret

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.

Calculation policy

How an AI agent should compute this KPI from messy company data. Free-text rules consumed at reasoning time — not a deterministic DSL. The most common ways to get this wrong are listed under Common miscomputations.

Inclusion rules

Engineering-attested estimate of the MONTHS of system capacity remaining at the current growth rate before the platform requires MAJOR (not incremental) infrastructure investment.
Driven by the single binding bottleneck (database shard / write throughput, message bus, single-tenant compute ceiling, regional capacity, compliance-driven re-architecture) — name the bottleneck alongside the months number.
Keep the growth-rate assumption explicit; recompute when the growth assumption changes or when capacity work lands.

Exclusion rules

Incremental / auto-scaling capacity the current architecture absorbs without a re-architecture project — that is not the binding constraint this KPI measures.
Cost headroom or budget runway — this is a technical-capacity horizon, not a financial one (finance.runway_months).
Hypothetical bottlenecks not on the current growth path — surface only the binding one.

Required inputs

The current growth-rate assumption (the denominator of the runway).
The binding bottleneck and its capacity ceiling at current load.
Engineering's estimate of months to that ceiling at the stated growth rate.

Data-source priority

Engineering / infrastructure leadership capacity model and load projections.
Observability / capacity-monitoring data (saturation trend on the binding resource).
Prior re-architecture project timelines as a sanity check on the "major investment" lead time.

Edge cases

Multiple plausible bottlenecks: report the nearest binding one and note the next — do not average them into a blended number.
A capacity project lands mid-period: recompute the months and re-name the new binding bottleneck.
Growth-rate assumption change: restate the headroom rather than holding a stale months number.

Validation checks

Compare against finance.runway_months: financial runway shorter than scalability headroom means the cash wall binds first; the inverse means the scale wall binds first and the rearchitecture belongs in the current operating plan.
Thin headroom paired with rising product.quality_churn_pct usually means the company is already hitting a reliability cliff — cross-check the two.
A months number with no named binding bottleneck is unverifiable — treat an unnamed estimate as not yet attested.

Common miscomputations

Reporting a headline months number with no named binding bottleneck — makes the investment decision impossible to act on.
Confusing scalability headroom (technical capacity) with financial runway (finance.runway_months) — they answer different questions.
Holding a stale estimate after the growth-rate assumption or a capacity project changed.

product.defensive_roadmap_pct
product.capacity_allocation_pct
product.quality_churn_pct
finance.runway_months
sales.growth_rate_yoy

Source

I'mBoard editorial — authored and maintained by I'mBoard, first published 2026-04-01. No third-party standard is cited for this KPI; when one emerges, the definition is back-attributed and promoted to the published tier (a minor version bump). Read the ontology methodology for the published vs editorial tier system, attribution rules, and dispute process.