Working with Features and Entitlements

Managing features and entitlements in Wingback is crucial for delivering a smooth customer experience and making sure appropriate functionality is available to each customer based on their plan. This guide will explain the difference between features and entitlements, as well as offer best practices for setting up and maintaining them in your product.

​

Features

Features are the basic building blocks of everything in Wingback and are crucial to manage and maintain carefully. While you might be used to working with feature flags in your product that map more into your development flow (for example, a new design for a dashboard or a change in button color), features in Wingback represent a customer-facing functionality of your product. Think of it as a permission to access parts of your product.

It’s important that your features map out correctly into your product. The list of features should be maintained by the development/product team, while other teams can use them to build plans. Each feature has a human-readable description and a slug. Once a new feature slug is created, it becomes immutable and cannot be modified.

​

Choosing the Right Feature Slugs

Choosing the right slugs is very important. Here are some rules:

• Only create slugs for the actual customer-facing functionality. Most features will be an action that your customer triggers while using your application.
  A helpful way to decide on your initial set of features is to look at the boundary between your backend and frontend. Most of your API endpoints should correspond to a feature in Wingback.
• Do not create slugs for things that are not part of your code base. “Great service” or “the leading solution in X” might be part of your sales/marketing copy but cannot be directly translated into your product.
• Avoid creating generic slugs, like CORE_PRODUCT or BASE; always look at actual features of your product. It can, however, often make sense to prefix your slugs if you have a complex application with many parts or panes.
• Never use quantifiers like 1000_OF_FEATURE_A as these limits might change in the future, and individual limits are fully configurable in the plan editor.
• Similarly, be careful not to accidentally create multiple slugs for the same feature.
• Don’t create slugs for features that are in development, as unreleased functionality might still significantly change or get abandoned. This is where you could use a feature flag solution during testing, and only add the actual feature slug in Wingback as part of your release process.

​

Examples

Each plan in Wingback is composed of features that your customers on that plan can access.

​

Entitlements

Entitlements are the customer-specific access rights to features based on their plan. They define which features are available to a customer, and in some cases, the usage limits or quotas for those features. As your customer base grows and more plans are created, there will be many different configurations and ways your customers pay for them. A customer might also upgrade, downgrade, or change their plan at any point. Entitlements can take many different forms, such as:

• Simple flat pricing
• Features with a limit on usage
• Usage-based pricing
• Bulk discounts
• Per seat pricing
• And many more…

Wingback’s Entitlement API simplifies the process of managing this complexity. As a developer, once you have integrated with the Entitlement API, all changes to plans and the plan’s feature configuration by your sales and marketing teams will automatically translate into Entitlements, typically requiring no further involvement from your side. This ensures that your application can adapt to new plans, feature configurations, and pricing models with minimal effort, allowing you to focus on developing and enhancing your product’s core functionality and forget about the complexity of plans and billing.