Per-editor AI credit limits

I made the case to halve the per-editor credit allowances before per-user pricing launched. Grounded in usage data, cost math, and a philosophy the room could align on.

Overview

Balsamiq AI had been in beta with no credit limits and no billing. I owned two connected shipments: taking AI out of beta with per-space credit limits in February 2026, and then arguing to halve the per-editor allowances before per-user pricing launched in May. The final numbers — 500 / 1,000 / 2,500 credits per editor per month for Starter, Teams, and Enterprise — are what shipped and are live on balsamiq.com/pricing today.

My role

• Wrote the pitch to take AI out of beta, add credit limits, and lead onboarding with AI instead of the project picker.
• Ran the usage analysis (BAIS database + PostHog) that grounded both v1 allowances and the later argument to halve.
• Made the case in the room to halve per-editor allowances before per-user launch, against pushback from three different directions.
• Landed the decision that shipped.

The challenge

Balsamiq AI was hidden. Users returned for the product's ease of use but didn't know we had AI. When they did discover it, they were delighted. Meanwhile, AI was still in beta with no credit limits and no billing, and onboarding started with the project picker, not with AI. We needed to take AI out of beta, add credit limits users could trust, and stop hiding the feature.

Later, while QA-ing the new per-user pricing billing page, the per-editor numbers we'd pitched for the new plans (1,000 / 2,000 / 5,000) started to feel too big relative to what people were actually using. The question: fix or ship?

Objectives

• Take Balsamiq AI out of beta with credit limits users trust.
• Lead new-user onboarding with AI, not the project picker.
• Add self-service credit top-ups for users who need more.
• Land per-editor credit allocations that match actual usage, not aspirational usage.

Strategy and execution

The philosophy that guided both phases

"Electricity, not parking meter." Most users should never think about the limit. Generous with paid, conservative with trial. Overages exist as backup for edge cases. Revenue grows through adoption, not through squeezing power users.

Phase 1: Out of beta with per-space limits (Feb 2026)

• Wrote the pitch: per-space credit limits, self-service top-ups, remove beta labels, lead onboarding with AI.
• Grounded the pitch in a week of usage data and a cost-basis check: at the proposed allowances, most paid users stayed comfortably under the limits.
• Shipped independently, before the per-user pricing migration.

Phase 2: The call to halve per-editor allowances (April-May 2026)

While QA-ing the new billing page, the per-editor numbers pitched for per-user plans started to feel too generous against actual usage. I brought the question to the room. Positions split three ways: some pushed for tighter caps as an upgrade lever; some worried tighter caps would burn existing heavy users; some argued the priority should be improving the feature itself before touching limits.

I wrote a follow-up analysis to ground the call in data: an internal database pull for ground-truth heavy sessions, PostHog behavioral patterns, and competitive benchmarks across Figma, Miro, Lovable, Whimsical, and Visily.

Heavy usage was rare and evenly distributed. A small share of paid AI spaces had multiple heavy sessions in the analysis period, with only a handful in the top usage bracket. Heavy sessions themselves were productive iterative work, not runaway usage. At halved numbers we'd sit in the competitive middle with the friendliest top-up shape (pooled + one-time vs recurring). The room aligned on halving: 500 / 1,000 / 2,500.

Point of view: moving a room with data, not authority

Pricing calls without authority are made or broken by whether the analysis is defensible. Halving was the data floor: conservative enough to preserve the electricity feel, generous enough to keep existing heavy users covered, with a 90-day review baked in as insurance.

The muscle isn't "I set a credit number." It's using data to reframe the conversation so the compromise becomes the version the room can align on.

Why it matters

The repeatable move: bring the number, bring the reasoning, bring the escape hatch. The room aligns because the analysis reframes the alternatives, not because you outranked anyone.