Credit Model

Trouble starts when a product grows features that cost money every time someone runs them. Summarizing a document means paying for an external model call. Exporting a large file or sending a text message carries a per-item cost too. A flat monthly subscription can't absorb that. Two customers pay the same price while one runs the feature three times a month and the other runs it three thousand times, and the second one wipes out the margin on that whole plan.

Moving to per-use billing runs into a different wall. The customer has no idea what the invoice will say until the month closes. Someone who got a budget of $400 a month approved internally is in an awkward spot when a bill for $950 arrives. Teams that live through that once don't get better at using the feature — they turn it off. The seller ends up no better off either, with next month's revenue impossible to forecast until the meters are read.

The credit model solves both by changing the order in which money moves. Counting usage stays exactly the same; what changes is that the customer buys what they expect to use instead of being billed afterward. They work knowing nothing can be charged above the amount they chose, and the seller collects cash before the costs are incurred.

A customer buys credits in a bundle, and every time a metered feature runs, a set amount comes off the balance. Five decisions define the design.

1. Deduction unit — how many credits a given action costs. Five credits per document summary, twenty per large export. That number is set against the per-item cost of goods sold (COGS), the money that actually goes out to perform the action. Set it out of line with cost and heavy users become the most expensive customers to serve.
2. Bundles — the sizes credits are sold in. Typically 10,000 credits for $40 and 50,000 for $160, so the price per credit drops as the purchase grows. Larger bundles pull in more cash at once and cut how often a customer has to decide about buying again.
3. Balance display — show the remaining balance and the cost of the current action before it runs. Without it people press buttons without knowing what comes off, and eventually stop pressing them.
4. What happens at zero — either lock the feature and prompt a top-up, or auto-recharge a card on file. Auto-recharge keeps work from stopping, but it weakens the budget control that makes this model attractive in the first place.
5. Expiry — how long purchased credits stay valid, commonly twelve months. Without an expiry, credits bought years ago keep stacking up and the accounting for them gets messy. Too short a window and customers feel cheated, which shows up as a refusal to buy the next bundle.

Cash arriving early doesn't make it revenue. Until credits are actually spent, the money sits as deferred revenue — an amount received for something not yet delivered, so it can't be counted as revenue yet.

The natural fit is a product where each action produces a traceable cost. Calling an external API, the interface one program exposes for another to send requests to, is the standard example: the bill from the provider scales directly with usage, so the charge to the customer scales with it too. Credits simply move that charge earlier.

It also suits how larger companies buy. A business that gets an invoice for a different amount every month has to route each one through approval again. One purchase order at the start of the year, covering a year of credits, turns that into a single step. Being able to promise finance that the number won't move is often what gets the purchase approved at all.

Credits also stack on top of other models rather than replacing them. A product can charge per seat for the base plan and sell only the expensive features as credits, which keeps the predictable part predictable.

It does make life harder for anyone watching monthly recurring revenue (MRR), the revenue that comes in on repeat each month. Top-ups land in lumps while consumption spreads out, so this month's incoming cash says nothing about whether the customer is still using the product. Teams running credits watch burn rate instead of purchases. A customer who never spends what they bought is unlikely to buy again.

"Don't fold this one into the subscription, put it on credits. The per-call cost goes straight out the door."

Inside a flat plan, the heaviest users turn into losses.

"Raising the summary from 5 credits to 8 is a price increase, let's call it that."

The credit count looks unchanged while the same money buys less work.

"Top-ups are up this month but burn is at 40 percent. Don't read that as revenue."

Money came in, and the customer isn't using the product at the same rate.

Pagedeck had this argument while launching document summaries. Mia wanted the feature bundled into the top plan. Theo came back with the cost of a single call, and with the fact that customers migrating an internal wiki sometimes run hundreds of summaries a day — one such company was enough to erase the plan's margin. Summaries went onto credits, with a monthly allowance included in each plan.

Grace attached one condition: the run button always shows the credits it will consume and the balance left. Sofia's most frequent question on sales calls was "how much does pressing this cost me?"

The most common error is reading prepaid money as revenue. It really did land in the bank, so the reading is easy to reach. But that money turns into revenue only as credits get spent, and until then it's closer to a debt — something to deliver or eventually write off. A team that plans a quarter around top-up totals gets hit twice when top-ups pause: no new money comes in, and the costs of serving credits sold last quarter keep going out.

The second error is assuming this is always the friendlier deal for the customer. Paying only for what you use does avoid waste. But a visible balance makes people price every action. Watching five credits leave for one summary invites a moment of weighing whether this document is worth five credits, and repeated often enough, that hesitation turns into using the feature less. Put a feature that should become a habit behind credits and customers start rationing it before they ever learn it.