A specific, common pricing question doesn't get enough direct attention: you have an existing product with existing pricing, and you're adding a genuinely new AI-powered feature. Do you fold it into the existing price, charge separately, or something in between? This is a narrower, more concrete question than "how should AI products be priced" in general, and it deserves its own framework because the existing pricing structure and customer expectations constrain the decision in ways a brand-new product doesn't face.

Option one: fold it into the existing price

Including the new AI feature in the existing subscription price, at no additional charge, works well when the feature's underlying cost is low relative to what customers already pay, and when the feature is more about improving the existing value proposition than creating a genuinely new one. A writing tool adding an AI-assisted grammar suggestion to an existing per-seat subscription is a reasonable candidate for this — the cost per use is likely small relative to the existing subscription price, and the feature enhances the core product rather than creating a distinctly separate value stream.

The risk: if the feature's actual cost is higher than initially estimated, or if usage patterns turn out to be far heavier than expected, folding it in for free can quietly erode margins in a way that's hard to reverse later without a customer-relations problem — removing or adding a charge for something customers have gotten used to as free is a much harder conversation than pricing it correctly from the start.

Option two: a separate, add-on charge

Pricing the AI feature as a distinct add-on — an extra monthly fee, a separate tier — makes sense when the feature delivers meaningfully new value on top of the core product, rather than just enhancing what was already there, and when the cost of delivering it is significant enough that folding it into existing pricing would require raising the base price for everyone, including customers who don't want or need the new feature.

Note

A useful test for this option: would raising your base price for every existing customer, specifically to cover this feature's cost, be a defensible ask even for customers who never use it? If the honest answer is no, that's a sign the feature belongs as a separate charge rather than folded into a price increase that effectively makes non-users subsidize users.

Option three: usage-based pricing layered on top of the base subscription

This fits particularly well for AI features with real, variable underlying costs — features involving significant model inference cost that scales with how much a customer actually uses it. A base subscription covers the core product as before, with the AI feature billed based on actual usage (per document processed, per query, per generated output) rather than either baked in for free or charged as a flat add-on that doesn't reflect how differently customers might use it.

This option requires the most work to implement well — you need actual usage tracking and a billing system that can handle metered charges — but it's often the fairest model when usage genuinely varies a lot across your customer base, since a flat add-on charge either overcharges light users or undercharges heavy ones relative to actual cost and value delivered.

The decision framework, concretely

Ask three questions in sequence. First: is the underlying cost of this feature low and fairly consistent per customer, or does it scale meaningfully with usage? If low and consistent, folding it into existing pricing is reasonable. If it scales with usage, lean toward usage-based or a metered add-on.

Second: does this feature enhance the existing core value proposition, or does it represent a genuinely new, separable value stream customers might want independently of the base product? If it's genuinely separable, a distinct add-on or tier makes more sense than folding it in, both for clarity and because it lets customers who don't want it avoid paying for it.

Third: what will customers actually expect, given how similar features are priced elsewhere in your market? A feature that's become an expected baseline capability across your competitive set is harder to charge separately for than one that's still a genuine differentiator — pricing against market expectation matters as much as pricing against your own internal cost structure.

A common mistake: deciding based on what's easiest to implement, not what actually fits

The most common misstep is choosing the pricing model that's simplest to build — usually folding the feature in for free, since it requires no new billing infrastructure — without seriously evaluating whether the underlying economics actually support that choice. This works out fine when the feature's cost genuinely is low and consistent; it creates a real, hard-to-reverse margin problem when a team discovers months later that usage and cost were much higher than assumed, after customers have already come to expect the feature as a free part of the product.

Revisiting the decision is normal, not a sign of a mistake

It's reasonable to launch a new AI feature folded into existing pricing while usage patterns and costs are still being learned, with an explicit plan to revisit the pricing model once real usage data exists — this is a more honest approach than guessing at a separate pricing structure before you actually know how customers will use the feature. The mistake isn't starting with a provisional pricing choice; it's failing to revisit it once real data exists to make a better-informed decision.

Building and Monetising AI-Powered Businesses walks through this exact decision framework applied to several real product examples, including one company's actual transition from folding an AI feature into existing pricing to a usage-based model once real cost data revealed the original choice was quietly eroding margin on the heaviest-usage accounts.