On usage-based credits, plan systems, and why building this yourself is a whole sub-system—and how credits.dev can help.
Both Polar and credits.dev are built for developers, but they solve different problems. Polar focuses on subscriptions and payments for open source; credits.dev focuses on usage-based credits and metering. Here's how to choose.
Stripe excels at payments and subscriptions, but metering usage and managing credits requires building on top. credits.dev is purpose-built for usage-based credits and plans. Here's when to use each.
Step-by-step tutorial on connecting LemonSqueezy payments to credits.dev metering. Handle subscriptions, one-time purchases, webhooks, and refunds with full code examples.
What starts as a single column in the database quickly grows into plans, grants, expirations, and more. Before you know it you've got a whole product inside your product. A guide for developers.
Credits and plans are infrastructure, not a one-off feature. The ongoing cost of maintenance, pricing experiments, and compliance diverts engineering from what differentiates you.
Admin UIs for support, grant/revoke/refund flows, and a full audit trail are non-negotiable in production. Here's what that work actually entails.
Plan definitions evolve: new tiers, grandfathering, per-customer overrides. Here's how to store and version plans so you can change them without breaking production.
Plan active/expire/renew semantics, timezone edge cases, and trial-to-paid transitions. How to get scheduling right in a credits system.
Mapping credit packs and plans to invoices, handling refunds and chargebacks, and keeping usage and revenue aligned. The finance layer of a credits system.
Renewals, expirations, notifications, and analytics all depend on jobs that run on schedule. How to design them so they don't silently fail or drift.
From a single balance column to a ledger and plan layer: schema options, tradeoffs, and how to support upgrades, top-ups, and manual adjustments.