Every team building a SaaS product eventually shops for the same three things: billing, tenancy, identity. And every shopping trip turns into the same spreadsheet, with a column per vendor and a row per feature, as though the decision were a sum of ticks.

It usually is not. Before any feature comparison means anything, there is a prior question that the spreadsheet hides:

Which shape do you want this thing to be?

Every problem in this category comes in three, and the shape decides more about your next five years than any row in the matrix.

The three shapes

A hosted platform. Metronome, Orb, Stripe Billing, Clerk, Auth0. Somebody else runs it. You integrate, and they take a percentage of revenue you already earned, or a fee per user you already acquired, for as long as you have customers. Your business logic lives on their servers, behind their uptime.

A deployed service. Lago, OpenMeter, Kill Bill, Keycloak. Free to license, and genuinely good software. It is also a second system: its own database, its own API, its own workers, its own upgrade path and its own failure modes, sitting beside the app you actually came here to build. You do not pay a percentage. You pay in operations.

An embedded library. This is the shape QuxKit takes. A dependency you install. It runs in your process, against the database you already operate, writing to tables in your own schema. There is no second service to deploy, no percentage to hand over, and no network hop between your application and its own data.

Three shapes, three bills, three failure modes. The features overlap enormously. The shapes do not overlap at all.

What the shape actually decides

The shape is not an implementation detail that you can refactor later. It decides four things that are very hard to reverse:

Where the money goes. A percentage of revenue compounds with your success. A per-active-user price compounds with your growth. A library is a dependency, and dependencies do not have a revenue share.

Where the failure lands. When a hosted platform is down, your login is down and your status page has to explain somebody else's incident. When a deployed service falls over at 3am, it is yours to restore, and it has a whole runbook of its own. When a library throws, it throws inside a process you are already watching.

Who owns the data. This is the one people notice last and care about most. If your customer records, your usage events and your ledger live in somebody else's system, then "export" is a feature you have to hope they prioritise. If they live in your database, they are simply your tables.

What happens when you want to leave. A dependency you can read, fork and keep. A platform you can only migrate away from.

None of that makes the hosted shape wrong. It makes it a trade, and the trade is the shape, not a feature.

billing-kit against Lago: the sharpest test

Comparing a library to a hosted platform is mostly comparing business models. The interesting comparison is against the other open thing, because there the difference is not open versus closed. It is library versus platform.

Lago is the sharpest test available: open-source, usage-based, payment-agnostic, and seriously built. The vocabulary below follows Lago's own glossary so the read stays apples-to-apples.

Capability	Lago	billing-kit
Metering: idempotent event ingest	yes	yes
Exact money: integer minor units, ISO-4217	partial	edge
Double-entry, append-only ledger	no	edge
True-up: estimate vs actual, per currency	yes	edge
Subscriptions, seats, trials, proration	yes	yes
Tiered and hybrid pricing, coupons, wallets	yes	yes
Payment-agnostic (Stripe, Paddle, and others)	yes	yes
Invoicing: line items, PDF	yes	delegated to the provider
Taxes	yes	by design: an interface
Dunning and failed-payment recovery	yes	by design: an interface
Analytics: MRR and churn	yes	no

Three of those rows deserve their plain reading.

"Edge" means the correctness model goes deeper. Amounts are integer minor units in a bigint, never a float, so a per-token rate prices to a fraction of a cent without drifting. Underneath sits a double-entry, append-only ledger that cannot be written out of balance. That is a guarantee rather than a habit, and it is the reason a retry converges on the same answer instead of charging twice.

"Delegated" means it happens across the settle line. Invoicing with line items and a PDF is real work, and the payment provider you already use does it. A billing library that grew its own invoice renderer would be duplicating something you are already paying for.

"By design" means we will not build a worse one inside a billing library. Tax and dunning are whole products with whole companies behind them, and they change by jurisdiction and by quarter. The kit ships the interface where a real engine attaches. That is an honest boundary, not a gap we are quietly hoping you miss.

And then there is the row with a plain "no": Lago gives you MRR and churn analytics, and billing-kit does not. If a ready-made revenue dashboard is what you are shopping for, that is a real reason to pick Lago.

Tenancy: where the boundary lives

Clerk Organizations, WorkOS and Auth0 Organizations are the hosted shape of this problem, and their org UIs and invitation flows are genuinely good.

	Hosted org products	tenant-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 to tenant resolution	SDK middleware	Typed extraction, then membership-checked authorization
Cross-tenant leak failure mode	Their incident, your disclosure	An empty result set
Orgs UI, invitations, admin portal	Included, polished	By design: build on the directory, or bring theirs

The row worth sitting with is the failure mode. The classic multi-tenant breach is one forgotten condition in one query. In the hosted shape, isolation is a promise made by an API you call correctly. In the embedded shape, isolation is enforced by the database underneath the query, so a read that forgets whose rows it is asking for returns nothing at all instead of returning another customer's data. The mistake stops being a disclosure and becomes an empty result you notice in development.

tenant-kit deliberately does not compete on the org UI. It owns the boundary: the directory, the resolution, and isolation you do not have to remember. The workflow layer is yours, or theirs.

Identity: where credentials live

	Hosted identity	identity-kit
Where credentials live	Their cloud	Your database, protected properly
Sessions	JWTs, their issuer	Server-side, revocable, idle and absolute lifetimes
Pricing	Per MAU after the 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

That last row is the whole argument in one line. If your identity provider is down, nobody signs in, and there is nothing you can do except wait and post an update. A library cannot have that outage, because it is not a separate thing that can be down.

And the row above it is the honest cost. Mature hosted identity products ship compliance dashboards and anomaly detection built by teams who do nothing else. A library ships invariants. If you need the dashboards, buy the dashboards.

What the embedded shape costs you

Since this is meant to be the honest read, here it is in one place. Choosing the library shape means giving up:

a ready-made organisations UI and invitation flow
MRR and churn analytics out of the box
compliance dashboards and anomaly detection
tax and dunning engines, as opposed to the interfaces they attach to
somebody else being on call for it

Some of those are deliberate boundaries and some are simply work we have not done. We have tried to be clear above about which is which, because a comparison that only lists wins converts nobody who has done their homework, and our buyers do their homework.

How to test the claim

The cheapest way to evaluate an embedded library is to notice what it is not asking you to do. There is no account to create before you can read the code, no service to stand up before you can run a test, and no meeting required to see the schema.

This portal's own login runs on identity-kit, so the identity comparison is one you can exercise rather than take on faith. The full capability matrix, with its receipts, lives in the docs.

Pick the shape first. The features are a much easier conversation afterwards.