Add-On Pricing Experiments Versus Inclusive Feature Upgrades
Splitting a feature into add-ons risks churn; bundling it risks leaving revenue on the table.

Pricing used to be a decision a company made once a year, maybe twice. That era is over. A pricing guide covering the top 500 SaaS and AI companies counted more than 1,800 pricing changes across that group in 2025, roughly 3.6 per company. Buried inside nearly every one of those changes is the same fork: should this capability be a line item customers pay for separately, or does it belong in what they already bought? Most teams get this wrong because they treat it as a pricing question first. It's a fit question first, and only becomes a pricing question once fit is settled.
Sell a feature separately that customers had already assumed was included, and you hand a competitor an easy pitch while inviting churn. Folding a feature into a higher tier that most customers have no intention of upgrading to leaves revenue on the table while teaching the market to undervalue the feature. Neither failure is theoretical. Zylo's SaaS Management Index found that 61% of organizations cut projects or initiatives last year because of unplanned SaaS cost increases. Buyer backlash already appears in budget line items and cancelled renewals, and it is visible there because vendors keep treating packaging as a decision made once, rather than a live one they need to keep revisiting.
Criteria for add-on pricing versus tier inclusion
Most product and pricing teams start with a price point. That's backwards: fit determines the answer, not price. Fit determines the answer, not price: does a feature serve the broad majority of customers on a given tier, doing the same job most of them are already there to do, or does it serve a narrower slice with a genuinely different need?
One workable framework sets the threshold at 60% to 70%. If that share of customers on a tier actively wants a given feature, it belongs bundled into that tier. Below that range, keep it as an add-on or a metered charge. Pushing a feature into a separate line item when adoption already sits above that threshold asks most of your customer base to pay twice for something they consider baseline, and the friction that creates has no real justification behind it.
Run a second test alongside the adoption threshold: remove the feature and watch what happens to the core workflow. If the product breaks, or becomes genuinely frustrating to use without it, that feature belongs in the base plan no matter what the adoption numbers say. If the workflow holds up fine and the feature only matters to a specific subset of use cases, add-on territory is defensible.
Gartner has a name for what happens when vendors ignore both tests: "hostage features." These are capabilities that feel, structurally and functionally, like they belong in the core product, but get locked behind an extra charge anyway. The pricing guide referenced above found that 64% of customers who switched vendors named unexpected costs for features they considered standard as their primary reason for leaving. That's a majority of churned accounts pointing at the same root cause, and it's the clearest evidence available that hostage features cost more than they earn.
Two cautionary cases: Notion's forced bundle and Cursor's variable credit shock
Two examples, documented by buildmvpfast.com, show what happens when a company changes its add-on structure without first reckoning with how customers will respond.
Notion's AI features launched as an add-on, priced at $8 to $10 per seat, available on any plan a customer already held. That changed in May 2025, when Notion moved AI exclusively into its Business plan at $20 per seat per month. Free and Plus users were left with roughly 20 AI trial responses and no way to buy more even if they wanted to. The backlash centered less on the price increase itself and more on what customers were being forced to buy alongside it: SAML SSO, private teamspaces, features many of them had no use for. One Reddit user summed up the frustration bluntly: "Under the same price we can have our own API and do whatever we want without being limited to a Notion website. The pricing is insane." The misjudgment traces straight back to the adoption threshold. By 2025, AI writing assistance wasn't a niche capability for a subset of knowledge workers anymore, it was close to table stakes. Running that feature through the 60-70% test would have flagged the risk before launch, not after the forum threads started.
Cursor's case looks different on the surface but shares the same root cause. Cursor moved from a predictable requests-per-month plan to a variable credit pool, and at least one developer watched a single session generate a bill of $7,225. The reaction on Hacker News was immediate: "Is that even legal?" CEO Michael Truell issued a public apology on July 4, 2025, along with refunds. Variable pricing itself wasn't the failure; plenty of usage-based models work fine. The failure was shipping variable pricing without a spend cap, without real-time visibility into consumption, and without any mechanism to stop a bill from spiraling before a customer even knew it was happening.
What connects both cases is process. Adequate warning reached neither company's customers. Neither offered a grandfathering path. Neither built in a safety valve, whether that's a hard spend cap, a grace period, or simply the option to keep the old add-on running while people adjusted. When a pricing change skips a grandfathering path, a safety valve, and real advance warning, it stops being a pricing experiment. It becomes a trust event waiting to happen.
The "AI tax" pattern: how vendors are using bundling as an account-expansion lever
Vendors now reach for bundling as a lever at renewal season. Zylo's index found that 79% of IT leaders hit a price increase at renewal over the past year, and a Gartner analyst confirmed that subscription costs from several large vendors climbed 10% to 20% in 2025, badly outpacing the 2.8% growth most IT budgets were planned around.
One pricing analytics vendor has a name for this squeeze in the context of new technology features: the "AI Tax," a 20% to 37% price uplift that becomes visible at renewal when a vendor bundles new capability into an existing product or pushes customers toward a pricier upgraded tier. That uplift travels through three mechanisms. Sometimes it's a straight list-price increase at renewal, no disguise involved. Sometimes it's a bundled tier upgrade, where a feature a customer already relies on gets quietly promoted into a higher-priced plan, so staying put means losing functionality. And sometimes it's a mid-term adjustment on a variable, consumption-based line item, one that shifts between billing cycles without triggering the kind of formal renewal conversation a customer would notice and push back on.
The pricing guide referenced earlier calls the broader trend the "great re-bundling of AI," and it runs along two tracks. Track A folds AI into existing plans as a bundled feature alongside a price increase: Notion, Slack, and Loom each charged $4 to $10 per user for AI as a standalone add-on at first, and each has since folded it into core plans with price increases in the $2.50 to $5 per user range. Track B folds AI in using credit limits instead, where access comes included but consumption still gets metered underneath.
What a well-designed add-on-to-bundle transition looks like
DeepL offers a cleaner version of this shift, documented by buildmvpfast.com. The company bundled its Write Pro AI add-on directly into its Business plan, but kept the same add-on purchasable standalone for Individual and Team customers. Lower-tier users get to test the feature without committing to a plan change, and Business customers simply get it as part of what they already pay for. Optional at the lower tiers, bundled at the top: nobody loses an option they already had.
Adobe's Firefly model works through a similar principle but with a sharper mechanical edge. Firefly comes bundled into Creative Cloud Pro or as a standalone plan, and both include a set quantity of monthly generative credits for premium generation, alongside unlimited access to standard generations. Standard Creative Cloud plans, by contrast, get limited credits rather than unlimited standard generations. The split that matters is between access and consumption: access to the feature is included, but the compute-heavy generation stays metered. That's the structural move that protects margin without making the buyer feel nickel-and-dimed for opening the tool.
Atlassian runs a comparable hybrid. Standard plans include 25 Rovo AI credits, and certain products, the Virtual Service Agency among them, can generate additional charges of $0.30 once a customer runs past what's included. Subscription, bundled entitlement, and consumption-based overage all sit inside a single contract. Whatever the specific mix, the working examples share one pattern: none of them strip optionality away from customers on lower tiers, and all of them make the consumption limits visible enough that a buyer can plan around them instead of getting surprised by an invoice.
When usage-based and credit-based pricing replace the add-on/bundle binary
Unlimited AI access wrapped inside a flat subscription can quietly wreck a company's margins once AI features carry real marginal cost, a dynamic pricing analysts have flagged directly. Every inference call costs something. Flat pricing just hides that cost until it doesn't.
That's part of why usage-based pricing has spread so fast. The share of SaaS companies using some form of usage-based pricing rose from 30% in 2019 to about 85% by 2024, and hybrid pricing models, blending subscription and consumption, jumped from 27% to 41% adoption in a single twelve-month stretch. Credits have become the connective tissue in that shift. They sit between flat access and pure outcome billing, giving customers more transparency than a traditional per-seat license, since they can see which actions consumed what, while remaining far easier for a vendor to implement than a true outcome-based system.
Clay illustrates the model cleanly. The company runs two expansion paths at once: feature-based subscription packages on one side, metered credit consumption on the other, with all plans including unlimited seats regardless of tier. Simplicity survives at the plan level even while the underlying usage gets tracked and billed with real precision underneath it.
Outcome-based pricing as the endpoint of the add-on evolution
Pushing the logic of usage-based pricing to its natural conclusion leads to outcome-based billing: charging for the job actually resolved rather than for access granted or consumption logged. Done well, this makes the unit being billed a result, and it erases the distinction between add-ons and tiers.
Zendesk became the first major incumbent SaaS vendor to put that model into production for AI agents, launching in August 2024. The billing unit is a support ticket resolved by AI without human intervention, confirmed after 72 hours of inactivity for email and web-form tickets, two hours for messaging channels. Pricing runs $1.50 per committed Automated Resolution and $2.00 per pay-as-you-go resolution. Gartner projects that 40% of enterprise applications will feature AI agents by the end of 2026, up from under 5% previously, and for genuinely autonomous workflows, billing by outcome is structurally the most coherent model available.
Structurally sound doesn't mean broadly deployable, though, and this is where most vendors overreach. Outcome-based pricing is the holy grail that stays out of reach for roughly 95% of the market, and chasing it before the infrastructure exists is the surer path to a trust crisis, not away from one. Attribution disputes are a real obstacle: who gets credit when a workflow touches both an AI agent and a human before resolution? Instrumentation is another, since a vendor needs airtight tracking of what counts as "resolved" before it can bill on that basis with any confidence. Zendesk's own 72-hour confirmation window gives away the difficulty here; it's a built-in admission that outcomes need time and verification before anyone can bill on them cleanly. Most products don't have that infrastructure yet, and building the billing model before the tracking underneath it is solid risks a repeat of Cursor's $7,225 invoice, with an even more opaque mechanism behind it.
A decision framework for choosing between add-on and inclusive tier
The choice between add-on and tier inclusion comes down to three questions, asked in sequence. The first "no" you hit tells you which path to take, and skipping the order is how teams end up guessing instead of deciding.
Start with the adoption threshold. Do 60% to 70% or more of customers on a given tier actually want or use this feature? A yes is a strong signal the feature belongs bundled into the tier. A no means it should stay an add-on, or move to a usage-based charge instead.
If that test passes, move to the core workflow test. Does taking the feature away leave the core job broken, or just meaningfully worse, for a typical user on that tier? A yes means the feature belongs in the base plan regardless of how the adoption numbers looked, since a broken core workflow costs more in churn than any add-on revenue could offset. A no means gating the feature, through an add-on or a higher tier, is still defensible.
Last comes the marginal cost test, and it's the one most teams skip, usually because it requires finance and product to actually talk to each other before a launch date gets set. Does this feature carry a real per-use infrastructure cost: compute, inference, API calls? If yes, flat inclusion at any tier risks quietly eating margin the way pricingio.com describes, and some form of credit system or usage-based overage needs to sit inside the design even if the feature is technically "bundled." If no, flat inclusion is economically safe, and the only remaining question is the adoption and workflow tests already answered above.
Running a feature through all three, in order, means the add-on-versus-bundle decision stops being a guess. It becomes a calculation, grounded in what customers actually use, what they can't function without, and what it actually costs to deliver. Skipping the sequence tends to produce an outcome that looks a lot like Notion's forum backlash or Cursor's $7,225 invoice: a pricing change that technically shipped, sitting on top of a customer base that no longer trusts the next one.


