January 28, 2026 | Adam Lantz
As an actively developed and actively used design system, Anvil2 faces a constant tension: the need to ship new capabilities quickly versus the requirement for rock-solid stability. If we wait until a component is “perfect” before you can touch it, we move too slowly. If we ship everything as stable immediately, we risk locking ourselves into APIs that don’t actually meet your needs.
Beta is how we solve this. It isn’t just a label for “unfinished” work; it’s a deliberate phase of collaborative development.
How do I know a component is in beta?
Transparency is key to managing risk. Every component in this phase is clearly marked with a callout at the top of its documentation page:
Beta FeatureThis feature is currently in beta, and needs to be imported from @servicetitan/anvil2/beta.While we hope to minimize breaking changes, they may occur due to feedback we receive or other improvements. These will always be documented in the changelog and communicated in Slack.Please reach out in the #ask-designsystem channel with any questions or feedback! Why do we make breaking changes in beta?
The primary value of a beta period is the freedom to iterate. When you use a beta component, you are participating in its final design.
If we discover through your feedback that a prop name is confusing, or that a layout behavior doesn’t work in a complex production environment, we want the flexibility to fix it. We make these changes now so that once a component moves to stable, it stays stable for years.
When we do need to pivot, we won’t leave you in the dark. We communicate every change in #ask-designsystem, record updates in our changelog, and aim to provide clear migration paths. Is it safe to use beta features in production?
The short answer is: yes, but with awareness.
We don’t put components into beta until they meet our standards for accessibility, performance, and visual quality. The “risk” isn’t that the component will break your app; it’s that you may need to spend an hour or two updating your implementation if we refine the API.
For many teams, the benefit of using a powerful new component like the DataTable today far outweighs the small cost of a future migration. If you’re unsure, reach out in #ask-designsystem. We can give you a sense of how close a component is to graduation.
When does a feature graduate to stable?
There is no fixed timeline for graduation. A component moves from beta to stable once it has “survived” production—meaning it has handled a critical mass of diverse use cases and gone through a period where no new API issues or architectural gaps are being reported.
While we don’t use a calendar to decide when a feature is ready, we are highly motivated to graduate features quickly. Leaving components in beta indefinitely is a failure of the system—it creates “import debt,” confuses adoption metrics, and makes it unclear what the “official” way to build a feature is. Our goal is to move through the beta phase as fast as your feedback allows.
Help us build the right thing
The best way to get a component out of beta is to use it and tell us where it hurts. Your input directly shapes the final, stable version of Anvil2. If you have questions or feedback, we’re always listening in #ask-designsystem.
