Gio Hobbins, co-founder of Schematic, breaks down the mechanics of credit-based pricing — why so many companies get it wrong, and what it takes to make it work. From defining the true value of a credit to managing burn-down, rollovers, and fairness, Gio explains how clear credit design can create predictable revenue and trust with your users. If your SaaS or AI product is considering a hybrid pricing model or exploring AI monetization, this session covers the playbook you need before you launch.
With SaaS you often pay even when you do not use it. Credits make unused value obvious, which can trigger cancellations if design is sloppy. You must be clear about the value of a credit, what counts as a successful use, the cost of an action, rollover rules, and overages.
Gio: I am a co-founder of Schematic. We started the company because changing pricing in past roles was painful. At my last company, adding an add-on or trying usage pricing meant months of engineering. We built Schematic so teams can evolve pricing without that drag.
Seat pricing is falling. Hybrids are surging. AI gross margins are lower than traditional SaaS. Infra costs are rising. Buyers struggle to predict spend. Let’s talk about the “how.”
Predictable cash flow: Prepaid credits give sellers upfront cash and give buyers a known pool to consume. Works for SMB and enterprise annual buys.
Hide complexity: Map varied, model-dependent costs to a simple internal currency. You price actions, not tokens.
User control: Top-ups, overages, and included credits can all coexist.
Hybrid-friendly: Credits pair well with seats or with non-credit usage meters.
Clear definition: Public, plain-English explanation of what a credit is and what it buys.
Estimator: “Tell us how you will use it” flow predicts needed credits before purchase.
In-product transparency: Balance, usage, and rollover are visible.
Line-item burndown: Users can see which actions consumed credits. This builds trust and is still rare.
Pegged to dollars: Credits purchased at face value reduce cognitive load.
Auto top-up and credit types: Plan, promo, and à la carte buckets.
Gaps: Hard to know expected burn per prompt or action. Error loops can eat credits without clear visibility. More pre-action transparency would help.
Vague credit definitions: Users cannot tell what a credit buys or when it is consumed.
No guardrails in onboarding: Trials that hand out credits with no seat belts lead to “I burned everything in minutes.”
Casino vibes: Everything costs a coin, nothing gives a coin back. Feels punitive.
Opaque overages and rollover: Unclear rules kill trust.
Front-loaded allocations without controls: Users trigger large actions early and churn when the balance disappears.
Tactics to mitigate:
Seat belts in trial: Caps, soft limits, and warnings on heavy actions.
Action-level pricing hints: Show expected credit cost before running.
Thoughtful rollover: Partial or month-only rollovers reduce the “I paid for nothing” feeling.
Overage options: Caps, throttling, or delayed true-ups.
Performance obligation: You cannot recognize revenue for unused credits until the obligation is satisfied or the credits expire.
Included vs standalone credits: Track and account for them separately.
Expiration matters: Standalone bundles need an expiry or revenue can be stuck.
Refunds and promos: Define policies up front; they impact recognition.
Gio: I showed a small “Price Spy” app that uses Schematic credits:
Customer portal: Plan, included credits, promo grants, buy-more, change plan, cancel.
Per-action costs: e.g., “snapshot” burns 1 credit.
Ledger: Every action mapped to a credit decrement, visible to the customer.
Back office: Define features, associate costs, entitlements, promotions, expirations, exceptions.
You can wire this up in Stripe, Metronome, Orb, or Schematic. The important bit is user-visible transparency and lightweight iteration.
Start with a value metric, not just cost plus. Cover variable cost, then anchor to outcome where possible.
Track everything. Instrument events, LLM model choice, and per-action cost.
Start simple. One credit type at launch is fine.
Build for iteration. Expect to test rates, caps, and rollovers.
Plan for complexity. As the product grows, you will monetize new actions. Keep user-facing rules simple even if internal logic gets richer.
How many credits for a trial? What research to run? Gio: Work backward from activation. Define the aha moment, list the actions to reach it, price those actions, then include enough credits to hit the moment multiple times. Use lightweight WTP interviews to sanity-check, but prioritize activation path analysis over heavy surveys.
What about the “I paid but did not use” problem? Gio: Rollovers help. Even partial or month-only rollovers reduce regret. Make the rules obvious in product.
Why credits instead of pure usage? Gio: Credits create perceived control, enable prepayment, and let you abstract messy cost structures. Use them alongside seats or metered features when that supports clarity and trust.
Gio: Define credits clearly. Show action costs before execution. Expose a real burndown ledger. Offer rollovers and humane overage options. If you do those four things, credits can deliver predictable revenue for you and trustworthy spend for your users.