Every problem here has three shapes.
A hosted platform that runs it for a cut or a per-user fee; a service you deploy and operate beside your app; a library you embed in the app you already run. The family is the third shape, three times over. What follows is the honest read. The gaps are listed with the edges, because our buyers do their homework.
A % of revenue or per-user pricing, forever. Your logic on their servers, behind their uptime.
Free to license, expensive to operate: its own database, API, workers and failure modes.
A dependency. Your database, your process, your tables. No cut, no second system.
billing-kit vs Lago. The closest comparison
Lago is the sharpest test: open-source, usage-based, payment-agnostic. The difference is not open vs closed. It is library vs platform. Vocabulary follows Lago’s own glossary; the full matrix lives in the docs.
| Capability | Lago | billing-kit |
|---|---|---|
| Metering: idempotent event ingest | ✓ | ✓ |
| Exact money: integer minor units, ISO-4217 | ◐ | ✓ edge |
| Double-entry, append-only ledger | no | ✓ edge |
| True-up: estimate vs actual, per currency | ✓ | ✓ edge |
| Subscriptions, seats, trials, proration | ✓ | ✓ |
| Tiered / hybrid pricing, coupons, wallets | ✓ | ✓ |
| Payment-agnostic (Stripe, Paddle, …) | ✓ | ✓ |
| Invoicing: line items, PDF | ✓ | → provider |
| Taxes | ✓ | By design |
| Dunning / failed-payment recovery | ✓ | By design |
| Analytics: MRR / churn | ✓ | no |
✓ edge. The correctness model goes deeper · → provider: delegated across the settle line · By design. An interface where tax and dunning engines attach; we will not build a worse one inside a billing library.
Against the hosted platforms: Metronome, Orb, Stripe Billing. The comparison is shorter: they meter and invoice well, and they take a percentage of revenue you already earned, forever, on their servers. The trade is the shape, not a feature.
tenant-kit vs Clerk Organizations · WorkOS · Auth0 Organizations
| Hosted org products | The kit | |
|---|---|---|
| Where the boundary lives | Their API, their user model | Your database: enforced for you |
| Pricing model | Per monthly-active user, forever | Open source; free at any scale |
| Auth coupling | Their auth owns your login flow | Consumes any UserId; auth stays yours |
| Request → tenant resolution | SDK middleware | Typed extraction → membership-checked authorization |
| Cross-tenant leak failure mode | Their incident, your disclosure | Empty result set. The policy is the WHERE |
| Orgs UI, invitations, admin portal | Included, polished | By design: build on the directory, or bring their UI |
Their org UIs and invitation flows are genuinely good, which is why tenant-kit deliberately does not compete there. It owns the boundary (directory, resolution, isolation you do not have to remember) and leaves the workflow layer to you or to them.
identity-kit vs Clerk · Auth0 · Supabase Auth
| Hosted identity | The kit | |
|---|---|---|
| Where credentials live | Their cloud | Your database, protected properly |
| Sessions | JWTs, their issuer | Server-side, revocable, idle + absolute lifetimes |
| Pricing | Per MAU after free tier | Open source; free at any scale |
| MFA, API keys, social sign-in | Included | Opt-in entry points, same library |
| Compliance dashboards, anomaly detection | Included, mature | By design: a library ships invariants, not a SOC team |
| Uptime dependency for login | Their status page | None. It is your process |
This portal’s own login runs on identity-kit. The comparison you can test is at /signup.