Disconnected exports
Flag targeting, tenant IDs, ARR, support notes, and contractual promises live in different systems.
Every flag has a
customer. Find whose.
Your flag platform knows which flags exist. It does not know which customers depend on them or what revenue breaks if you remove one. Varistra is being built as the record that answers that, across flags and the workflows, templates, integrations, permissions, and contractual exceptions no flag platform holds. It is not generally available yet.
One governed inventory for
- feature flags
- workflows
- templates
- integrations
- permissions
- contract exceptions
Feature flag governance
A flag platform shows what runs. It cannot show what the business should keep.
A flag survives its release for a commercial reason, not a technical one. Nobody can prove which accounts still evaluate it, what recurring revenue is exposed if it is removed, or who is accountable for the answer. Lifecycle tooling finds the flag. It cannot make that call.
Flag evidence
Every flag connects to source rows, the accounts that evaluate it, the ARR behind them, and a review state.
Approved treatment
Remove, keep, package, reprice, or migrate, with an owner, a date, and the rationale.
Flag export to approved cleanup
One evidence chain. Seven accountable stages.
Varistra keeps source facts, calculation assumptions, financial context, and human decisions distinct, then connects them in a reviewable record.
- 01
Import source evidence
Load a flag or configuration export and an account revenue export. Nothing changes in LaunchDarkly, Unleash, Flagsmith, Statsig, or your own config service.
- 02
Validate coverage
Expose rejected rows, missing joins, currency boundaries, and source assumptions before anyone trusts a total.
- 03
Map product variance
Normalize flags together with the workflows, templates, integrations, permissions, and contractual exceptions no flag platform holds.
- 04
Connect customer impact
Show every account evaluating each flag, the value it receives, how common it is, and the recurring revenue protected by it.
- 05
Review operating burden
Attach usage, support, and maintenance evidence while keeping observed facts separate from proxies.
- 06
Approve treatment
Record whether to remove, preserve, migrate, bundle, reprice, or retire, with an owner and a written rationale.
- 07
Measure the outcome
Compare immutable snapshots and preserve the evidence behind every later correction or decision.
Built for the cleanup decision
Know the customer impact before you delete the flag.
Removing a flag is safe only when product, engineering, finance, and customer teams are reading the same account and revenue evidence.
Flag portfolioRank flag debt by revenue exposure, not by age
Compare how many accounts evaluate each flag, the ARR behind them, data coverage, burden signals, and decision state, without hiding missing evidence.
approval_flow14 accounts · $1.2M ARRStandardize
legacy_export3 accounts · $420K ARRMigrate
white_label1 account · $180K ARRReprice
Every number keeps its source
Rejected rows, joins, currencies, and calculation assumptions stay visible beside the result.
One record for product and finance
Review customer dependence, revenue exposure, product burden, and commercial timing together.
Observed facts before proxies
Usage, support, maintenance, and revenue signals remain labeled so false precision cannot pass as evidence.
Corrections do not erase review context
A later import, mapping, or decision creates a new snapshot or event instead of rewriting the original.
Commercial evaluation
Price the platform. Then govern what it leaves behind.
Each solution page explains the exact use case, evidence model, product boundary, evaluation criteria, and next purchasing step.
01
Ask about early access Feature flag governance software
Govern flag lifecycle by customer and revenue exposure, without replacing the platform that delivers flags.
Evaluate fit 02Feature flag tool pricing compared
Published prices, free tiers, and the seven different billing units eight vendors actually use.
Evaluate fit 03LaunchDarkly pricing explained
Service connections and client-side MAU, what moves each meter, and worked estimates from the published rates.
Evaluate fit 04Feature-flag cleanup template
Start a customer-aware stale flag audit with owners, targeting evidence, and treatment states.
Evaluate fit 05Feature flag tools vs. a decision ledger
Compare runtime feature management with the governance layer that sits above it.
Evaluate fit 06Beyond flags: customer configuration
Workflows, templates, integrations, permissions, and contractual exceptions no flag platform holds.
Evaluate fitStart with the evidence you have
You can run the first flag audit today, on paper.
The audit template below is free and needs no software from us. Export your flags with their tenant targeting and your accounts with ARR or MRR, and work through the field set. If the exercise is worth automating, tell us.
Use the flag audit template- 1Export accounts
Stable customer ID, ARR or MRR, currency, segment, plan, and status.
- 2Export flags
Customer ID, flag key, value, type, and source reference. Other configuration types load the same way.
- 3Approve one decision
Treatment, owner, timing, rationale, evidence, and revenue handling. Then tell us where it hurt.
A precise product boundary
Varistra governs flag decisions. Your flag platform still serves the flags.
Varistra does
- Inventory feature flags and every other customer-specific configuration
- Connect each flag to the accounts and recurring revenue behind it
- Preserve coverage, assumptions, and immutable evidence
- Record approved standardization treatments and outcomes
Varistra does not
- Evaluate feature flags in application code or ship an SDK
- Replace LaunchDarkly, Unleash, Flagsmith, Statsig, or a CMDB
- Claim complete customer profitability from configuration data alone
- Make roadmap, pricing, migration, or renewal decisions autonomously
Buyer questions
Evaluate a feature flag governance layer
What is feature flag governance?
Flag governance answers the commercial question a flag platform cannot: which customers evaluate this flag, how much recurring revenue depends on it, who approved keeping it, and when that decision is reviewed again. It is the layer above lifecycle tooling, not a replacement for it.
What is flag debt?
Flag debt is the set of flags that have outlived their release and cannot be removed, usually because nobody can prove which customers still depend on them. It is a record-keeping problem rather than a code problem, which is why a newer flag platform does not reduce it.
Who buys Varistra?
Product, engineering, product operations, and finance leaders, usually when a flag cleanup, packaging change, renewal, migration, or platform consolidation has stalled because nobody can produce a defensible customer-by-flag dependency map.
Does Varistra replace LaunchDarkly, Statsig, Split, or a CMDB?
No. Feature management platforms deliver runtime behavior, and CMDBs inventory infrastructure or IT assets. Varistra ingests their evidence and adds the customer, revenue, operating-burden, and decision layer.
Can we try Varistra today?
Not yet. Varistra is in development and there is no self-serve signup. The feature flag audit template on this site is free and usable now with nothing but a spreadsheet. If you want to be part of the early work, use the contact form.
How does Varistra calculate the ARR behind a flag?
It links each accepted account to the flags and variants assigned to it, preserves currency boundaries, reports rejected or unmatched rows, and never sums overlapping account revenue across several flags. It does not claim to be a complete customer profitability calculation.
Does Varistra decide which flags to remove?
No. Varistra makes the evidence and the assumptions reviewable. Authorized people publish the treatment, rationale, owner, timing, and revenue handling.
Make the next cleanup defensible
Audit the flags. Protect the revenue. Approve the removal.
Varistra is in development and not generally available. If flag debt is already blocking a decision on your side, tell us what the blocker is. We would rather build against a real case than a guess.