You can gate a feature with an if (user.plan === 'pro') check. It works — until the customer upgrades mid-session and the app doesn't know until the next reload, or downgrades and keeps a feature they no longer pay for because nothing revoked it. Onelo flags exist to remove exactly that class of bug: a flag scoped to a plan, pushed live to every connected client the instant billing state changes, with a real locked-state UI instead of a feature that just silently doesn't work.
| What has to work | Hand-rolled plan check | Onelo feature flags |
|---|---|---|
| Turn a feature on for Pro | An if-statement reading subscription status. | A flag scoped to a plan — same idea, wired for you. |
| Reacts to an upgrade | Only on the next request or app restart, unless you build a push channel yourself. | Pushed to connected clients over a live stream the moment billing state changes. |
| Reacts to a downgrade / cancel | Same gap — stale access until something re-checks. | Revoked the same way, over the same stream. |
| Locked-feature UI | Usually just hidden, or a blank state. | A dedicated "upsell" visibility state, distinct from hidden/greyed/coming-soon. |
| Percentage rollouts / targeting rules | Not unless you build it. | Basic targeting/rollout on Pro+ — not an experimentation engine. |
| A/B testing, statistical significance | Not unless you build it. | Not offered — see LaunchDarkly instead. |
LaunchDarkly answers a genuinely hard, generic problem: how do I roll a change out to 1% of users, test two versions against each other, and target a flag by arbitrary user attributes at scale? That's deliberately decoupled from any particular billing system, because LaunchDarkly's customers build their own entitlement logic on top of it.
The question a solo dev usually has is smaller and more specific: a customer paid for Pro, so this feature should turn on for them right now, not after a reload — and turn back off the moment they downgrade. Onelo flags answer exactly that. A flag isn't just a boolean; it has a visibility state — enabled, greyed, hidden, upsell, new, beta, or coming soon — so a locked feature can prompt an upgrade instead of just disappearing, and state changes reach the client over a live connection rather than waiting for a poll interval.
Onelo flags are not an experimentation platform — no percentage rollouts beyond basic targeting/rollout rules (Pro plan and above), no A/B testing, no statistical significance layer. If the actual need is running controlled experiments across a large user base, or targeting by arbitrary user attributes at scale, LaunchDarkly is built for exactly that and is the better fit. Onelo trades that breadth for being wired to billing out of the box, at no extra integration cost beyond the plan you're already on.
Branded hosted page + social login, wired for you — not a component you assemble.
You're the seller of record. Onelo Tax computes EU+UK VAT per buyer.
Refunds, cancel, plan change, invoices — self-serve, no support tickets.
Plan-gated entitlements tied to billing, with an upsell prompt on the locked ones.
HTTP monitors + incidents, auto-opened and auto-resolved.
Bug/feature reports from inside the app, with a public voting roadmap.
Pre-launch signups that auto-swap into the store the day you launch.
Versioned legal docs, re-consent, marketing checkbox, audit trail.
Every hosted screen carries your colors and logo, not Onelo's.
The stuff you rebuild on every project, in one place — one SDK per platform (Web/JS, Swift, Kotlin, Flutter, React Native, Electron; Python/Node/PHP on the backend).