Skip to content

Usivity vs feature flags

Flags release what you built. Usivity fits it to each user.

Feature flags and per-tenant configuration switch on what your engineers built, for the users or accounts you choose. Usivity lets each user change how the product looks and shows their data, in plain language.

See a live demoAll comparisons

The short answer

  • Use feature flags when you release, test or switch off features your engineers built, or give each plan what it pays for.

  • Use Usivity when a user wants the product to look or work differently for them, with no new variant in your code.

  • One user or a whole account. Your team writes a change once and sends it to the account’s users, so nothing is set up user by user.

  • Side by side. Flags decide which features exist for whom. Usivity fits them to each user.

Side by side

Feature flags and per-tenant config and Usivity, compared.

The same customer request, handled two ways.

Feature flags and per-tenant config compared with Usivity
QuestionFeature flags and per-tenant configUsivity
What it isSwitches in your code that turn features on or off for chosen users, accounts or a share of traffic. Per-tenant configuration stores settings for each account that your code reads.A layer in your app that changes how the product looks and shows data for each user, inside the zones you choose, from a plain-language request.
Personalized for each user or account?Per account, plan or segment, and only between variants engineering built. No flag holds a version per person.Yes. Each user gets their own changes, and your team can send one change to a whole account.
Who makes the changeEngineers build each variant behind the flag. Product or engineering decides who gets it.The user, in their own words. Or your team, from the Usivity portal, sent to one user or a whole account.
Time to changeFlipping a flag is instant. Anything new has to be built and released first.Seconds for the user, with nothing to build first, within what Usivity can do.
Engineering effort (code)High effortBuild and test every variant, then remove flags that are no longer needed. Each tenant setting is code that reads it.Low effortOnce: one script tag and a server-signed user identity. None per change.
Team effortIntake, sizing, prioritization, escalation, testing, upkeepHigh effortDecide who gets what, test the combinations, and keep track of which account has which setting.Low effortUsers ask for what they want and get it. Your team writes account setups in the portal, with no ticket to size.
What your team learnsWho has which feature, and how a rollout or experiment performs, depending on your tooling.What each user changed and asked for, in their own words, including what the product couldn’t do yet.
Risk to your code and dataFlags live in your code. Old ones pile up, and every combination is something to test.Nothing in your code. Personalizations change presentation only, never write to your backend, and switch off in one click.
Good fitWith caveatsPoor fit$ to $$$$ relative effort, not priceScroll the table sideways to see every column.

Which to choose

Flags are for releasing software. Not for fitting it to each user.

Usivity doesn’t release features, run experiments or manage entitlements, and isn’t meant to. Flags can’t give every user their own version of the page. Here is which to reach for.

Use feature flags when…

  • Rollouts

    You’re rolling out a new feature.

    Release it to a few users or accounts first, then widen it.

  • Kill switches

    A feature misbehaves.

    Turn it off without a new deploy.

  • Experiments

    You’re testing two versions.

    Run them against each other and measure the result.

  • Plans

    Each plan gets what it pays for.

    Entitlements by pricing tier or contract.

  • Account behavior

    It changes what the product does.

    Rules, limits or integrations for an account. Usivity never changes business logic.

Use Usivity when…Usivity

  • One person

    Every user wants something different.

    No flag holds a variant per person. Usivity keeps each user’s changes for that user.

  • Small requests

    It’s a request you’d never flag.

    Rename a label, hide a column, highlight overdue rows, add a total. Too small for engineering, real for the user.

  • Accounts

    An account wants its own setup.

    Your team sends it to the whole account, with no settings screen to build.

  • No variants

    You want nothing new in your code.

    Personalizations live outside your code, so nothing piles up in it.

  • Learning

    You want to learn what to build next.

    Every request is recorded, with Reports on what sticks and what the product couldn’t do.

  • Undo

    It must be simple to switch off.

    Users turn their own changes off, and one switch in the portal turns Usivity off for everyone.

Using both

Flags release the feature. Users make it theirs.

Feature flags decide which features exist for whom. Usivity lets each user shape how those features look and work for them.

  1. 1

    Ship behind a flag

    Engineering releases a new feature to the accounts you choose.

  2. 2

    Users fit it to their work

    Each user changes how it looks and shows their data, inside the zones you open.

  3. 3

    Reports show the next default

    What users change most is a candidate for the default in your next release.

Frequently asked questions about Usivity and feature flags.

Is Usivity a feature flag tool?

No. Feature flags switch on features your engineers built, for the users or accounts you choose. Usivity lets each user change how the existing product looks and shows their data, in plain language. It doesn’t release features, run experiments or manage plans.

Can Usivity turn a feature on or off for an account?

Not in the feature flag sense. Usivity changes presentation inside the zones you allow, such as hiding a column, and your team can send a change to all of an account’s users at once. Hiding something with Usivity is not access control: what users can see and do stays with your code.

Do we have to make a change for each user, one by one?

No. A user’s own request changes their view alone, but your team can describe a change once in the Usivity portal, find an account’s users by company and send it to all of them at once. Each user gets their own copy. Nothing is added to your code, so there is nothing to roll out.

Do we still need per-tenant configuration?

For settings that change your product’s behavior or data for an account, yes. For preferences about how the product looks and shows data for a person, such as columns, labels, views and highlights, Usivity can take the place of settings you would otherwise build.

Can we turn Usivity itself off?

Yes. In the portal you choose which users get Usivity, and one switch turns it off on your site for everyone at once. Personalizations are kept, and come back when you turn it on again.

Compare

Other comparisons.

The other ways teams handle requests to change how the product looks and shows data.

All comparisons
Usivity compared

Your customers get a product that fits. Your roadmap stays yours.

In ten minutes we’ll show you what your customers can change on their own, and what your team never has to build.

Book a 10-minute demo

We reply within one business day.