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 | — | ✓ 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 | ✓ | — |
✓ 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 — forced row-level security |
| Pricing model | Per monthly-active user, forever | Apache-2.0; 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, database-enforced isolation) 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 Postgres — argon2id + an app-held pepper |
| Sessions | JWTs, their issuer | Server-side, revocable, idle + absolute lifetimes |
| Pricing | Per MAU after free tier | Apache-2.0 |
| 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.