Why does flat-monthly break for AI-feature SaaS?

Flat-monthly assumes COGS is small (5-10% of revenue). AI features push COGS to 30-60% via vendor token costs. The long tail of heavy users eats margin if the model does not meter their consumption.

Should I move all pricing to usage-based?

No. Most successful pivots keep flat-monthly as the base and add metered overage only on the AI-cost-driving feature. The customer's mental model stays mostly the same; only the long tail starts paying for their consumption.

How do I price the included quota and the overage rate?

Set the quota at the 90th percentile of usage among existing customers (so 90% never see overage). Set the overage rate at 2-3x your underlying cost (matches the margin multiple of your base plan). Round to clean numbers.

How do I migrate existing customers to the new pricing?

Email at announcement, send a per-customer pre-view ('here's what you'd pay under the new pricing'), grandfather early customers for 12 months as a goodwill gesture, apply new pricing to new signups immediately. Skipping this sequence produces angry Reddit threads.

How long does the pricing pivot take?

Three to four weeks for a side project: one week meter, one week price analysis, one week dashboard + emails, one week migrate. The metering and the dashboard are the real engineering; the rest is communication.

Pricing for high-COGS side projects: when flat monthly breaks

The HN Ask thread (HN 47797882, 2026-04) was titled "What pricing model works for high COGs side project?" The post described a familiar arc: the side project shipped, the first ten paying customers came in at $19/mo flat, the maker built an AI feature, customers loved it, the OpenAI bill went from $20 to $400 in two months, and the maker realized flat monthly was no longer the right model.

An r/SaaS thread from 2026-05 ("Most AI SaaS pricing is broken. We tried something different across 9 models — here's the markup map and why") walked through the same problem at greater volume: nine pricing models tested, four lost money on every heavy customer, three barely covered AI cost, two were structurally sound. The pattern across the two threads is clear: the AI-feature shift broke a pricing model that was working fine for the pre-AI product.

This article is the three-step pivot.

Why flat monthly worked, then stopped working

The 2020-era SaaS pricing model assumed COGS was small. A typical SaaS: 5-10% of revenue went to Stripe + hosting + email. Flat monthly at any price worked because the marginal cost of one more customer was nearly zero. The math: charge $19, pay $2, profit $17, scale on customer count.

The AI-feature shift broke that. A typical AI feature SaaS has COGS of 30-60%: OpenAI tokens, Anthropic tokens, sometimes Replicate or ElevenLabs or Whisper. The marginal cost of one more customer who actually uses the AI feature is real money. The math: charge $19, pay $7 (AI cost on a heavy customer), profit $12. Profit on a light customer is still $17, but the average across heavy and light is the question.

What broke: the heavy customers are not the median, they are the long tail. 10% of customers consume 60% of AI cost. Flat monthly assumes the median; the long tail eats margin if you let it.

The three-step pivot

The fix preserves flat monthly as the headline price (so existing customers' experience does not change) and adds metered overage on the AI-cost-driving features. Three concrete steps:

Step 1: Identify the cost driver and meter it

One feature, usually one AI vendor, is responsible for 80% of the cost. List the API calls firing per customer per month. Sort by cost contribution. The top one is your meter.

Add a meter event for each call. The event should record customer ID, timestamp, token count (or unit count), vendor, and cost-attributable amount. Fire it from your no-code platform's outbound webhook or your backend's middleware.

This is the diagnostic phase. Two weeks of metering tells you exactly which customers consume what, in dollars not tokens.

Step 2: Define the included quota and overage rate

Now you have data. The plan should include a quota that covers your 80th-90th percentile customer. If the 90th-percentile customer uses 400 prompts at $0.02 each ($8 cost), set the included quota at 500 prompts and price the plan at $29 (covers $10 of AI cost with margin).

The overage rate covers your underlying cost plus the same margin multiple. If a prompt costs $0.02 and your base plan is ~3x cost, overage is $0.06. Round to $0.05 for communication clarity.

For credit packs (if your unit is expensive), the math is similar: cost per unit + margin = pack price ÷ pack size. Don't mix soft cap and credit packs on the same feature.

Step 3: Ship the dashboard and the email cadence

The customer needs to see what they are using. Drop a usage bar into the product. Send three emails: at 50% of quota ("you're at 50%, no action needed"), at 80% ("approaching quota — here's the overage rate"), at 100% ("you're now in overage at $0.05/prompt"). Three touches beat one surprise invoice.

The math that this gets you

Before: flat $19/mo, 90th-percentile customer costs you $8 in AI = $11 gross profit = 58% margin on the heavy tail. Light customer costs you $0.20 in AI = $18.80 gross profit = 99% margin. Blended gross margin if 10% are heavy: ~95%, but the heavy tail's specific margin is 58%, which means as you scale and the heavy tail gets longer, blended margin compresses fast.

After: flat $29/mo with 500-prompt quota + $0.05/prompt overage. 90th-percentile customer at 400 prompts = $29 - $8 cost = $21 profit = 72% margin. Heavy customer at 1500 prompts = $29 + $50 overage = $79 revenue - $30 cost = $49 profit = 62% margin. Light customer at 50 prompts = $29 - $1 cost = $28 profit = 97% margin.

The blended margin holds at 80%+ across the customer distribution because the long tail now pays for itself. Three weeks of pricing engineering recovers years of margin.

What this is not

It is not a price increase for everyone. Customers on the median pay the new base price ($29 vs $19) but it is justified by the included quota. Light customers can be grandfathered or move to a smaller plan.
It is not "we're metering everything." One meter on the cost-driving feature. Other features remain flat.
It is not a rebuild. The meter sits outside the product; the no-code app fires events; the metering service does the math.

The communication that matters

The single most important thing during the pivot is communicating it well to existing customers. The pattern that works:

Email at announcement-time: "We're changing pricing on [date]. Here's why. Here's what stays the same. Here's what changes for you specifically."
Per-customer pre-view: "Based on your last 90 days, here's what you'd pay under the new pricing." Most customers will be at or below the new base; the surprise is gone.
Grandfather option for early customers: 12 months at the old price as a thank-you. Cheap goodwill, retains the cohort that has been with you longest.
New pricing applies to new signups immediately; existing customers migrate on a posted date.

Skipping this sequence is what produces the Reddit threads titled "[product] just changed pricing without warning."

What I would actually do

Week 1: meter the cost driver. Add events to your no-code app's outbound flow.
Week 2: analyze and price. Quota at the 90th percentile, overage rate at 2-3x cost.
Week 3: ship the dashboard and the email cadence. Bar, three touches, customer self-throttles or self-upgrades.
Week 4: pivot live for new signups. Old signups grandfathered for 12 months.

The honest framing: AI-feature SaaS broke the 2020 flat-monthly default. The fix is small and proven, and it pays back the first month. The maker who waits a quarter on the old pricing is paying for the heavy tail out of pocket; the maker who moves quickly recovers margin and learns the model.