Credit Packs over Subscriptions

Instead of forcing users into recurring commitments, I offer credit packs that allow them to pay for specific units of product usage as needed. This approach shifts the focus from continuous subscriber retention to delivering clear, measurable value with each unit consumed.

What it is

Credit packs are a monetization model where users purchase a fixed quantity of "credits" or "units" upfront. These units are then depleted as the user engages with the product's core functionality. Unlike subscriptions, there's no auto-renewal, no monthly billing cycle, and no inherent pressure to use the product constantly to "get their money's worth." For example, Inky offers 5-pack and 15-pack options for image generation. A user buys a pack, generates images, and their credit balance decreases. When they run low, they purchase another pack. It's a direct transaction for a specific output.

Why I do it this way

I use credit packs to better align perceived value with actual use. Subscriptions often create renewal anxiety for users and churn drama for the business. Users might feel locked in or resent paying for a service they didn't fully utilize that month. With credit packs, the user knows exactly what they're paying for and what they're getting in return. This transparency reduces friction at the point of purchase and minimizes the operational overhead associated with managing complex subscription lifecycles—dunning emails, prorated refunds, upgrade/downgrade logic. It also simplifies the product's value proposition: X credits for Y output. This aligns with my approach to Stop Short of Perfection, focusing on the core value exchange rather than building out elaborate billing systems. My goal is to deliver a functional product that solves a problem, and credit packs support that directly without adding unnecessary complexity.

How it works in practice

The implementation is straightforward. Stripe handles the one-time payment processing for credit pack purchases. Once a transaction is confirmed, a Firebase Function updates the user's credit balance in their Firestore document. When a user initiates an action that consumes credits—like generating an image in Inky—another Firebase Function validates their balance, deducts the required credits, and then triggers the core product logic. If the user's balance is too low, the transaction is rejected, and they are prompted to purchase more credits. I use Resend to send automated notifications when a user's credit balance falls below a certain threshold, prompting them to top up. The user dashboard, hosted on Vercel, displays their current credit balance and a history of their transactions and usage. This entire flow is documented meticulously, a practice that feeds into Document While Shipping, ensuring clarity for future iterations or debugging. Even parts of the credit monitoring and top-up prompting can be managed by agents, as outlined in Agent-First Development, reducing manual oversight.

Where this breaks down

While effective, this model isn't without its trade-offs. The most significant is the lack of predictable recurring revenue that subscriptions offer. Revenue becomes more transactional, tied directly to user activity and repurchase cycles. This requires a consistent focus on user acquisition and delivering value that encourages repeat purchases. Defining the unit of value can also be a challenge; it needs to be clear, measurable, and consistent across product features. For products with continuous, high-volume, or background usage (e.g., monitoring services), a flat-fee subscription might be simpler for users to understand and manage. Users might also forget to top up their credits, leading to gaps in usage or a perceived interruption in service. This model also doesn't inherently build the "stickiness" that a subscription might, where users are incentivized to keep using a service simply because they are already paying for it monthly. It demands that the product consistently earns its usage.