What is your deprecation and end-of-life policy? Enterprises build on platforms; platforms that yank features without process get ejected in the next renewal cycle.?

The full executive answer

The policy has an enforced tier and a committed tier, and I will be precise about which is which. Enforced today, in code: the public API is versioned with an OpenAPI specification that carries explicit deprecation markings, so integrations always see sunset status machine-readably; webhooks are published through a typed catalogue so event contracts are explicit; exports run through a versioned subsystem; and every change lands in the public changelog. Data outlives features by policy — our retention module classifies business and tenant data as "retain", never auto-pruned, so a deprecated module’s historical outputs remain exportable rather than vanishing with the UI.

Committed, as stated policy: changes are additive-first — deprecation is the last resort after migration paths exist; a minimum twelve-month sunset window for any API version or module an Enterprise customer actively uses, with notice through the changelog and direct communication; and no silent removals — a feature’s disappearance without a deprecation notice would be treated as an incident, not a decision. Pre-launch is honestly the cheapest moment to establish this: with no customers, we could churn features freely — writing the policy now, before it constrains us, is the point.

The reason this matters commercially, not just technically: platform trust is the renewal. A boardroom operating system asks customers to accumulate decision memory inside it for years — the deprecation policy is really a data-longevity promise, and ours is that your history is never hostage to our roadmap.