Jekyll2026-08-20T00:45:00+00:00https://subscrio.com/feed.xmlSubscrioSubscrio is the entitlement engine that translates subscriptions into feature access. Open-source library plus paid Server App.Jasen FiciFeature flags are not entitlements2026-08-19T00:00:00+00:002026-08-19T00:00:00+00:00https://subscrio.com/blog/feature-flags-are-not-entitlementsTeams often wire LaunchDarkly (or a homegrown flag table) into the same places they check a Stripe plan name. It works until someone sells a custom seat count, a trial that should not include SSO, or a downgrade that has to wait until the period ends.

Those are different jobs.

What a flag is for

A flag decides whether a build of the product should show a path. Percentage rollouts, kill switches, beta cohorts. The question is “is this code live for this request?”

Flags do not know if the subscription is cancelled. They do not create a default plan when a customer has none. They do not walk override, then subscription, then plan, then default.

What an entitlement is for

An entitlement answers “is this customer allowed to do this?” You ask it on button clicks, resource creates, and API calls. The answer has to stay true when billing changes without a deploy.

That is the layer Subscrio is. The library is open source. Your app still owns UX. Stripe still owns money. Subscrio owns the translation between a paid plan and a feature value.

A smell in the codebase

If you grep for plan === "pro" in a dozen files, you do not have an entitlement model. You have a pile of conditionals that will rot the first time sales needs an exception.

Check a named feature instead. Let one resolver walk the stack. Keep flags for shipping code, not for “they paid for ten seats.”

Where to go next

The docs cover the catalog model. The Web Admin page is the commercial console for the same catalog if you do not want to mutate it only in code.

]]>Jasen Fici