How do you handle unused credits?

Credits typically do not expire. This reduces user anxiety and encourages larger initial purchases, trusting they'll eventually use them. It also simplifies the backend logic and reduces administrative overhead.

What's the optimal credit pack size?

We test a few tiers (e.g., small "starter" pack, medium "standard" pack). Inky currently offers 5 and 15 credits, a balance between low commitment for new users and a slight bulk discount for more active users.

Does this work for all product types?

It's best for products with discrete, measurable actions or outputs that can be easily quantified per credit. It's less suitable for continuous access or "all-you-can-eat" models where usage is hard to quantify on a per-credit basis.

Concept · monetization · in production

Credit-Pack Monetization

One-time credit purchases offer a non-subscription monetization model, aligning user value with product usage while mitigating common churn associated with recurring payments.

What it is

Credit-Pack Monetization is a payment model where users purchase discrete bundles of credits, each representing a unit of service or access, which are then consumed over time rather than paying a recurring subscription fee. Instead of a monthly commitment, users acquire a finite pool of currency that they spend on specific product features or outputs. For instance, our product Inky operates exclusively on this model, offering users packs of 5 or 15 credits. Each credit corresponds to a single generative AI operation, such as creating a piece of content or generating an image. This approach shifts the user's mindset from a continuous drain on their wallet to a transactional purchase tied directly to perceived value and usage.

Why it matters

This model sidesteps several common challenges associated with traditional subscriptions. Foremost, it significantly reduces churn. Users don't "forget" to cancel a recurring payment; they simply run out of credits and repurchase when needed. This aligns the cost directly with the value derived: a user who needs more output buys more credits, while an infrequent user isn't overcharged for unused subscription time. For Total Ventures, this translates to more predictable revenue streams, as credit pack sales are a direct indicator of active usage intent. It also simplifies customer support by minimizing billing disputes related to recurring payments and cancellations. The lower barrier to entry, compared to a monthly commitment, often encourages initial adoption, as users can test the waters with a smaller credit pack.

How TV applies it

At Total Ventures, Inky serves as the primary example of Credit-Pack Monetization in action. Users purchase credit packs directly through Stripe Checkout, a process designed for minimal friction. Upon successful payment, our backend, primarily built on Firebase Cloud Functions, updates the user's credit balance in Firestore. Each time a user initiates a generative AI task—be it a content draft or an image creation—the system first verifies sufficient credits. If available, one credit is decremented, and the request proceeds to the underlying LLM. This credit-based execution is a core component of our Tool Use Pattern, where specific actions or API calls consume a defined unit of value. Complex operations, potentially involving chained prompts or multiple steps within Agent Memory Systems, are often bundled to consume a single credit, simplifying the user's understanding of cost. Frontend credit displays, built with Next.js and hosted on Vercel, provide real-time updates to users. Furthermore, any operation requiring precise data formatting, often leveraging Structured Output via Zod, is also credit-gated, ensuring that valuable processing power is only expended when a user has committed resources. Post-purchase, automated receipts are dispatched via Resend, reinforcing the transactional nature.

Common failure modes

Implementing credit-pack monetization is not without its pitfalls. Overly complex credit systems, with multiple credit types or confusing expiry rules, can quickly alienate users. Simplicity in pricing and usage is paramount. Another challenge is "credit hoarding," where users purchase packs but then don't engage with the product, leading to a disconnect between sales and active usage. This can be mitigated by clear value propositions for each credit and encouraging immediate use. Pricing is a constant iteration: under-pricing devalues the product, while over-pricing stifles adoption. It's crucial to ensure that users clearly understand what one credit "buys." Finally, robust and accurate credit tracking is non-negotiable; any discrepancies in a user's balance can quickly erode trust and lead to support overhead.

FAQs

How do you handle unused credits?: Credits typically do not expire. This reduces user anxiety and encourages larger initial purchases, trusting they'll eventually use them. It also simplifies the backend logic and reduces administrative overhead.
What's the optimal credit pack size?: We test a few tiers (e.g., small "starter" pack, medium "standard" pack). Inky currently offers 5 and 15 credits, a balance between low commitment for new users and a slight bulk discount for more active users.
Does this work for all product types?: It's best for products with discrete, measurable actions or outputs that can be easily quantified per credit. It's less suitable for continuous access or "all-you-can-eat" models where usage is hard to quantify on a per-credit basis.

Want to see this pushed into production?

See the experiments →