Stigg feature modeling: the five mistakes that bite (seats, IDs, cadence)

TL;DR: Fix: use a configuration feature with a per-unit charge. Context: Official docs (Stigg skills repo, stigg-pricing-modeling/references/features.md): documents the five common feature-modeling mistakes that trip integrations, plus feature type rules, metered aggregation behavior, and reset-cadence guidance. Features are the building blocks: boolean (has access or not), configuration numeric/enum (a bound value), metered (consumption over time paired with a meter).

Context: Official docs (Stigg skills repo, stigg-pricing-modeling/references/features.md): documents the five common feature-modeling mistakes that trip integrations, plus feature type rules, metered aggregation behavior, and reset-cadence guidance. Features are the building blocks: boolean (has access or not), configuration numeric/enum (a bound value), metered (consumption over time paired with a meter). The feature type is fixed at creation and cannot be changed later.

The five mistakes, with fixes straight from the reference: 1. Modeling seats as a metered feature. Fix: use a configuration feature with a per-unit charge. Metered is for time-series consumption (api calls, tokens), not counts that change rarely. 2. Putting feature IDs in user-facing copy. Fix: IDs (apicalls, activeseats) are referenced from your code on every entitlement check, treat them as part of your public API. Keep them stable and machine-readable; show the name in UI. 3. Adding boolean features for tiered values. Fix: one configuration feature carrying the value beats five booleans. 4. Mismatching reset cadence and billing period. Fix: daily resets on a monthly bill confuse customers; align them (monthly resets for monthly periods). 5. Designing aggregation around current product behavior. Fix: aggregations other than count need an explicit dimension (sum needs the bytes dimension, count_unique needs the customerId dimension). Add as many event dimensions as you can up front; backfilling them later is painful. Also: editing a feature group propagates to all plans using it, and archiving hides a feature from new plans while existing subs keep their values.

When to use

You hit exactly this: Stigg feature modeling: the five mistakes that bite (seats, IDs, cadence) in Stigg feature modeling.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Stigg feature modeling.

Edge cases

• Also: editing a feature group propagates to all plans using it, and archiving hides a feature from new plans while existing subs keep their values.

Official docs page: https://github.com/stiggio/skills/blob/HEAD/skills/stigg-pricing-modeling/references/features.md. What it documents: Official docs (Stigg skills repo, stigg-pricing-modeling/references/features.md): documents the five common feature-modeling mistakes that trip integrations, plus feature type rules, metered aggregation behavior, and reset-cadence guidance. Features are the building blocks: boolean (has access or not), configuration numeric/enum (a bound value), metered (consumption over time paired with a meter). The feature type is fixed at creation and cannot be changed later. The verified guidance distilled above: The five mistakes, with fixes straight from the reference: 1. Modeling seats as a metered feature. Fix: use a configuration feature with a per-unit charge. Metered is for time-series consumption (api calls, tokens), not counts that change rarely. 2. Putting feature IDs in user-facing copy. Fix: IDs (apicalls, activeseats) are referenced from your code on every entitlement check, treat them as part of your public API. Keep them stable and machine-readable; show the name in UI. 3. Adding boolean features for tiered values. Fix: one configuration feature carrying the value beats five booleans. 4. Mismatching reset cadence and billing period. Fix: daily resets on a monthly bill confuse customers; align them (monthly resets for monthly periods). 5. Designing aggregation around current product behavior. Fix: aggregations other than count need an explicit dimension (sum needs the bytes dimension, count_unique needs the customerId dimension). Add as many event dimensions as you can up front; backfilling them later is painful. Also: editing a feature group propagates to all plans using it, and archiving hides a feature from new plans while existing subs keep their values.