The Auth Pricing Cliff That Kills Small Software

Someone on your team built something useful last week. A dashboard for the one number everyone keeps asking about. A tracker shaped like how your team actually works, instead of how Jira thinks it should. An agent wrote most of it, and it took an afternoon.

It is still running on their laptop.

Not because deploying is hard — deploying has been a solved problem for a decade. It is still on their laptop because the moment you want one other person to use it, you hit a wall that has nothing to do with your code.

The wall

Put the app on the internet and anyone can read it. So you need a login. And the moment you need a login, you are choosing an identity provider, wiring OAuth, modelling users and sessions, deciding what each person can see, and figuring out what happens when someone leaves the company.

That is days of work. For an app whose actual business logic is two hundred lines.

So you look for something to buy. And this is where it gets strange.

Free, and then a cliff

Here is what the identity vendors charge, as of July 2026:

Look at the shape of that. The free tiers are enormous — a million monthly active users, fifty thousand, twenty-five thousand. Then the next step is a hundred and twenty-five to three hundred dollars a month.

Your app has three users.

You are not near any free-tier limit and you never will be. But the thing you want — let my three colleagues sign in with the work account they already have — is a feature, not a volume. And it lives on the far side of the cliff.

Why the pricing is shaped like that

None of this is a mistake. These products are built for a specific customer: a B2B SaaS company selling to enterprises.

WorkOS’s per-connection pricing makes complete sense in that world. Each “connection” is one enterprise customer’s identity provider, wired into your product so that customer’s employees can log in. If you have forty enterprise customers, you have forty connections, each generating real revenue. $125 each is trivially worth it.

Now apply that model to an internal tool. Your team wants to sign into its own dashboard using its own Google Workspace. That is one connection. You pay the same $125/month that a company would pay to onboard a paying enterprise customer — except this connection generates no revenue at all. It just lets Priya see a chart.

The free tiers are shaped by the same logic. A million free MAU is generous because the vendor is betting you are building a consumer product that will grow, and they will monetize you on the enterprise features later. The free tier is sized for scale you do not have and do not want.

There is no tier priced for a permanently small audience. Not a tier that is expensive — a tier that does not exist. Three to ten people, forever, who want SSO and will never need SCIM provisioning or audit exports or a compliance package. Nobody sells that.

The other half of the problem

Meanwhile, look at where you would host this thing.

Render, Railway, Fly, Netlify, Cloudflare Pages — every one of them is excellent at taking your code and giving you a URL. Not one of them has an opinion about who is allowed to open it. Railway has no access control layer at all. That is not a criticism; it is a scope decision, and it is the same decision all of them made.

So the two halves never meet. Every host is auth-agnostic. Every auth vendor is hosting-agnostic. Which means a three-person team building a three-person tool has to select two vendors, integrate them, and absorb two unrelated pricing models — one metered on compute, one metered on identity — to get to “deploy it, and let my colleague log in.”

For one small app, that is annoying. The team builds it anyway, or gives up.

For the tenth small app, it is the whole ballgame. Nobody is doing that setup ten times.

What the internal-tools platforms do instead

The obvious answer is to use something that bundles this. Retool, Airtable, Power Apps — they all include identity, and that is genuinely part of why people buy them.

But they solve it by charging per seat, which breaks in the other direction.

Retool’s Business tier is $50–65 per builder per month, and that is exactly the tier where SSO and governance live. Airtable bills every editor every month, whether they touched the base once or lived in it. Power Apps is $20 per user per month, and Microsoft retired the cheaper per-app plan in January 2026.

Per-seat pricing works fine when an app serves the whole company. It is backwards when the app serves three people, because the cost scales with the users while the value scales with… also the users. There is no leverage. A three-user tool cannot carry a fifty-dollar-a-seat platform fee, so it never gets built there — and the fiftieth small tool, the one with two users, definitely never gets built there.

That is the quiet reason so much small software stays a spreadsheet. Not because a spreadsheet is better. Because a spreadsheet does not require a procurement conversation.

Auth is a platform property

The framing mistake underneath all of this is treating authentication as something an application does.

It made sense when applications were big. If you are building one product that serves a million users, that product should own its identity model, because identity is part of the product.

But small software inverts every assumption there. The app is tiny. There are three users. The identity model is not a product decision — it is the same identity model your company already has, in Google Workspace or Okta or Entra, with the same people in it and the same person in HR removing them when they leave.

Writing that logic into each small app is not just wasteful. It is worse than wasteful, because now the answer to “who can see the revenue dashboard” lives in code that an agent wrote at four in the afternoon, and nobody reviewed it, and it is different from the answer in the other nineteen tools.

The correct place for that boundary is in front of the app, not inside it. An identity-aware proxy authenticates the request before it ever reaches your code, and hands the app a verified user. The app implements no auth at all. Sharing becomes a list of people, changeable without a redeploy. And when someone leaves, they are deprovisioned once — in the identity provider you already run — and lose access to all twenty tools at the same moment.

That is not a novel architecture. Cloudflare Access, Google’s IAP, and Vercel’s deployment protection are all versions of it, and every large engineering organization builds some flavour internally. What has never existed is that pattern priced and packaged for someone who has three colleagues and a FastAPI app, rather than for a platform team with a Zero Trust rollout plan.

What it should cost

The test is simple, and it is not about the first app.

It is whether your team can have twenty small tools alive at once without anyone doing arithmetic about it. Twenty tools, each with a handful of users, each occasionally opened, each behind your real identity provider. If the tenth one requires a pricing conversation, the tenth one does not get built — and the tenth one might have been the useful one.

That means the marginal cost of one more small app has to be close to zero, which rules out per-seat, and it means org sign-in has to be at the bottom of the pricing page rather than gated behind an enterprise tier. Right now nobody offers that combination. Replit gates SSO to Enterprise. Vercel gates SAML and SCIM to Enterprise and charges $150/month for advanced deployment protection on Pro. Lovable is the most generous of the group and still puts SSO at its $50/month Business tier.

The gap is not a small one, and it is not going to be closed by another auth SDK. It gets closed by treating hosting and identity as the same product — which is what we are building AgentCell to be.

AgentCell is the cloud for small software: one command to deploy the tool your agent built, and one email address to share it. Sign-ups are open. Deploy what you built.