Application Features
A feature is a capability of your application that can be turned on or off independently — the unit a subscription tier is built from.
Where to find it
Architect Panel → Subscriptions:
- Feature Sets — the groupings features are sold in
- Subscription Packages — the packages customers buy
Architect Panel → Security:
- Permissions — which controls who, not what is available
Features and permissions are different questions
The distinction that makes both work:
- A feature answers "is this capability available to this customer at all?"
- A permission answers "may this person use it?"
Both apply. A customer on a tier without advanced reporting does not have it however senior their staff; a customer who has it still restricts which of their people use it.
Conflating them produces either permissions that vary by tier — unmanageable — or features granted per person, which is not a subscription model.
Define features around what customers buy
Not around your code. A feature should be something a customer would recognise on a price list and might reasonably pay more for.
"Bulk export" is a feature. "The v2 report renderer" is an implementation detail, and making it a feature means your commercial model is shaped by your architecture.
Keep the list short
Every feature is a combination to support, a line on a comparison table and a thing that can be on in one place and off in another. Thirty features is a matrix nobody can reason about and a test burden that grows with it.
Most successful tiering uses a handful of features that genuinely differentiate.
Decide what happens when a feature is off
The part most often left to chance. Options, roughly in order of preference:
- Hidden entirely — clean, and customers do not know it exists.
- Visible but unavailable, with an explanation — a route to upgrade, and it must not feel like a fault.
- Failing when used — never acceptable; it reads as broken software.
Existing data when a feature is removed
Somebody downgrading may have data only that feature can reach. Decide whether it becomes read-only, hidden or exportable — because "inaccessible with no explanation" will generate a complaint and possibly a dispute.
Do not gate anything security-relevant
Audit, access control and data protection should not be tier-dependent. Selling security as an upgrade is a poor look, and it means your lower tiers are less safe for the customers least able to judge that.
Worked example
A product defines six features that customers recognise — advanced reporting, the API, bulk export, single sign-on, custom branding and extra storage. Audit and permissions are in every tier. Unavailable features are hidden rather than shown greyed out, except the API, which shows an upgrade route because customers ask for it.
Recommendations
- Keep features and permissions separate.
- Define around what customers buy, not your code.
- Decide the "off" behaviour for each feature.
- Never gate security features.