Application Features

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.

Adding a Feature

Adding a feature is a commercial decision as much as a technical one.

Where to find it

Architect Panel → Subscriptions:

• Feature Sets — the groupings features are sold in
• Subscription Packages — the packages customers buy

Settle these first

1. Which tiers include it? Including whether existing customers gain it.
2. What happens when it is off? Hidden, or visible with an upgrade route.
3. What happens to data if a customer later loses it.
4. Is it genuinely separable? A feature entangled with everything else is not one.

Existing customers are the hard question

Adding a feature to a tier gives it to everybody on that tier — usually welcome. Carving something they already use into a higher tier does not: it is a takeaway, and it will be received as one.

If you must, grandfather existing customers rather than removing something they have been using. The goodwill cost of the alternative is far higher than the revenue.

Introduce it off

Add the feature switched off everywhere, confirm nothing changes, then enable it where it belongs. That separates "the feature exists" from "the feature is on", and it means a mistake affects nobody.

Test both states

On, and off. The off state is the one that ships broken, because development happens with it on — and the failure is visible to exactly the customers who did not pay for it.

Test as a customer without the feature, not as an administrator.

Beware entanglement

If turning a feature off breaks something unrelated, it is not a separate feature. That is worth discovering before it is on a price list rather than after a customer downgrades.

Name it as customers will see it

It appears on comparison tables and invoices. "Advanced Reporting" is a name a customer understands; an internal code name is not, and renaming it later means changing published material.

Document what it includes

Precisely enough to settle an argument. "Advanced reporting" will otherwise mean different things to your sales team, your support team and your customer — and the customer's interpretation is the one you will be held to.

Worked example

A product adds bulk export. It is created off, tested in both states as a non-entitled customer, then enabled for the top two tiers. Existing customers on the middle tier who had been using an earlier informal export are grandfathered, and the feature description states exactly which formats and limits it covers.

Recommendations

• Create it off, then enable deliberately.
• Test the off state as a real non-entitled customer.
• Grandfather existing users rather than taking something away.
• Write down exactly what it includes.