Build vs Buy Auth Is the Wrong Question. Here's the Right One.

Every CTO re-litigates this decision roughly every 18 months. A vendor invoice arrives higher than expected, or a feature request dies in a vendor's backlog, or a new engineer asks why authentication costs more than the database, and suddenly the whole team is back in a conference room arguing build versus buy for authentication.

I've been in that room from every seat. I built LoginRadius, a customer identity platform, and scaled it past a billion users, which means I was the vendor other teams were deciding whether to buy. I've also mentored founders deciding whether to build their own, and I now watch startups make this call in real time through accelerator work. The pattern I keep seeing is that the debate is framed wrong before anyone says a word.

Build versus buy assumes a binary that stopped existing around 2020. No serious team builds authentication entirely from scratch anymore, and almost no team buys a vendor and writes zero identity code. Every real architecture is a hybrid. The only question that matters is where you draw the line, and "build or buy" is useless for answering that because it treats identity as one undifferentiated thing you either own or rent. It isn't one thing. It's two very different things wearing the same word.

The line that actually matters: commodity versus product

Here is the reframe. Identity splits cleanly into two categories, and they demand opposite decisions.

The commodity layer is everything that works identically for you and for a competitor in an unrelated industry: password hashing, OAuth and OIDC flows, SAML federation, session management, MFA delivery, token issuance and rotation, breach-password detection, the mechanics of a passkey ceremony. None of this is where you win customers. A user has never chosen one product over another because its bcrypt work factor was tuned more thoughtfully. This layer is pure table stakes, it's security-critical, it follows public standards, and it is a solved problem. Building it yourself means paying to reinvent something the whole industry already agrees on, and worse, owning the security liability when your reinvention has a flaw the standard implementations fixed years ago.

The product layer is everything that is specific to how your application works: your user and account model, your onboarding flow, your authorization logic, your multi-tenancy structure, the permission hierarchy that maps to how your customers actually organize their teams. This is not commodity. This is your product, and it often is a competitive differentiator, especially the authorization model. How you decide who can do what inside your application is frequently core to what your application is. A B2B SaaS company's entire enterprise-readiness story often lives in its authorization layer.

Once you see identity this way, the decision rule writes itself: buy the commodity, own the product. Rent the OAuth flows and the password hashing and the MFA delivery, because owning them is pure cost and risk with zero upside. Keep control of your authorization model and your user model, because those are yours and a vendor's generic version will fight your product's actual shape.

Almost every build-versus-buy disaster I've seen came from getting this backwards: teams that lovingly hand-built the commodity layer (and shipped a credential-stuffing vulnerability doing it) while accepting a vendor's rigid, generic authorization model that then constrained their product roadmap for years. They built the part they should have bought and bought the part they should have built.

What "building" the commodity layer actually costs

If you're tempted to build the commodity layer anyway, price it honestly first, because the sticker shock is real and it shows up late.

Building passwordless and passkey authentication from scratch typically runs more than 800 engineering hours and three to six months before a production-ready implementation ships, and that's the best case, before ongoing maintenance. That figure isn't a one-time cost either. The standards underneath are moving. OAuth 2.1 is consolidating years of security best practice into a single spec and is nearing finalization. The Model Context Protocol is defining how AI agents authenticate on behalf of users, and those patterns are shifting monthly. CISA's own 2025 guidance calls AI-agent authentication an emerging attack surface with no settled standard yet. Building the commodity layer doesn't mean writing it once. It means committing an engineer to tracking draft RFCs and shipping updates as the specs evolve, indefinitely.

This is why FusionAuth, itself a vendor and so not a neutral source, still lands on a number worth repeating: fewer than 5% of engineering teams should build authentication from scratch. Even discounting for the source, the direction is right. The commodity layer is where DIY almost always loses.

The four real architectures (and their honest costs)

"Where you draw the line" resolves into four practical patterns. Each is a legitimate choice for some team, and each has a cost that vendor pricing pages and open-source READMEs both understate.

1. Full SaaS CIAM (Auth0, Okta, Entra External ID, and similar). You buy the whole commodity layer and configure the product layer on top. Fastest to ship, lowest operational burden, and you inherit the vendor's compliance posture. The cost is per-user pricing that scales with your success and, more subtly, the limits of the vendor's authorization model when your product outgrows it. This is the right default for most B2B SaaS companies, with a caveat I've written about separately: the pricing only makes sense for the right buyer profile. I broke down who actually fits Auth0's model in Auth0 Isn't Overpriced, You're Just the Wrong Buyer.

2. Self-hosted platform (Keycloak, FusionAuth's self-hosted edition). You run open-source identity software yourself. No per-user fees, full control, and your data stays on your infrastructure, which is why regulated and high-volume shops reach for it. The trap is the word "free." Keycloak's license costs zero dollars; operating it does not. A production-grade high-availability cluster starts around $1,250 a month in infrastructure alone, and one detailed three-year TCO analysis put Keycloak's total ownership between roughly $199,000 and $211,000, with operational labor alone near $142,000, against about $19,500 in operational cost for a commercial alternative. On top of that, self-hosting makes every identity CVE your problem: 2025 alone brought a Keycloak trust-store bypass rated 8.2 and a TLS-renegotiation denial-of-service rated 7.5, the kind of advisory you patch the same week, not next sprint. Self-hosting trades a per-user bill for a standing operational commitment of roughly half to one full FTE. That trade is worth it at scale and punishing when you're small, which is the paradox: the option marketed as cheapest is often most expensive for the team with the fewest engineers to spare.

3. Auth library plus owned infrastructure (Lucia-style libraries, framework-native auth, SuperTokens self-hosted). You use a library for the commodity primitives and build the surrounding product layer yourself on your own database. More control than SaaS, less operational weight than a full self-hosted platform, and it keeps your user model genuinely yours. The cost is that you now own more of the security surface than the SaaS path, and you have to be honest about whether your team has the identity expertise to hold that responsibility as you grow. This is a strong fit for developer-heavy teams with an unusual user model that vendor products fight.

4. Full custom (build essentially everything). Almost always the wrong call, and I'll say that plainly. The one legitimate case: identity itself is your product. If you're building an identity provider, an authorization engine, or a security product whose entire value proposition is how it handles auth, then auth is not your commodity layer, it's your product layer, and of course you build it. For everyone else, full custom means paying billion-user prices in engineering time to solve problems a $240-a-month plan already solved.

The founder decision tree I actually use

When a founder in an accelerator asks me which way to go, I don't answer with a vendor name. I ask three questions, and the answers place them in one of the four patterns above.

Question one: Is identity your product, or a feature of your product? If you're building an auth or identity or security company, identity is the product, and you build (pattern 4). This eliminates the one case where full custom is correct, so ask it first. For everyone else, identity is a feature, and building the commodity layer is a distraction from your actual product. Move on.

Question two: How weird is your authorization and user model? If your permission structure is standard (users, roles, maybe organizations), a SaaS vendor's model fits and pattern 1 gets you to market fastest. If your model is genuinely unusual (complex delegation, deeply nested tenancy, relationship-based permissions that a role system can't express), you need to own more of the product layer, which pushes you toward pattern 3, and you should look hard at whether your authorization needs a dedicated engine rather than a bolt-on.

Question three: What's your scale trajectory and margin structure? If you're a B2B SaaS company where user count tracks revenue, per-user SaaS pricing stays proportional and pattern 1 holds up for a long time. If you're a high-volume, low-revenue-per-user product (freemium consumer app, AI-native community, anything where MAU outruns revenue), per-user pricing eventually breaks and self-hosting's fixed cost wins, pushing you toward pattern 2. This is exactly the wall the LogicBalls team hit, which forced our own migration and taught me that even a well-planned auth migration costs far more than the invoice it saves.

Three questions, four patterns. Notice that none of them is "build or buy." Every answer is a hybrid; the questions just locate where your line falls.

The trap nobody warns you about: the line moves

Here's the part that turns a good decision into a bad one 18 months later. The commodity-versus-product line is not fixed. It moves as you scale.

At 5,000 users, full SaaS CIAM is obviously right: you have no operations team and shipping fast is everything. At 5 million users, the same per-user pricing might cost more than the engineers it would take to self-host, and the line has moved. A decision that was correct at seed stage becomes a liability at Series C, which is why this debate recurs every 18 months. It's not that anyone chose wrong the first time. It's that the right answer changed and the architecture didn't.

So the actual skill isn't picking the perfect vendor today. It's architecting so you can move the line later without a rewrite. In practice that means one discipline above all others: build on standards, not on proprietary mechanisms. If your integration speaks plain OIDC, OAuth 2.0, and SAML, changing vendors is a configuration change. If you've wired your application into a vendor's proprietary hooks, custom rule engine, or bespoke SDK surface, changing vendors is a rewrite, and you'll delay the move past the point where it's clearly correct because the switching cost is too high. Every hour you invest in a vendor's proprietary extensibility is an hour you're pre-committing to spend again during a migration you can already predict. I've watched this specific lock-in strand teams in Auth Migration Hell, and it's why standards-first architecture is the single most protective decision in this whole space.

The same logic protects you from vendor mortality, not just vendor pricing. Standards-based integration is what lets you survive a vendor getting acquired and shut down, which happens in this market more than teams expect. I catalogued the full pattern in The CIAM Graveyard: the vendors that die take proprietary integrations down with them, while standards-based ones let you walk away with a config change.

If you want the systematic version of this decision rather than the napkin one, I keep it at CIAM Compass, including a dedicated build-versus-buy CIAM guide that runs the same commodity-versus-product logic down to named platforms and their real costs.

The bottom line

Stop asking whether to build or buy your authentication. That question forces a false binary and hides the decision that actually matters.

Ask instead which parts of your identity stack are commodity and which parts are your product. Buy the commodity, because owning it is cost and liability with no upside. Own the product, because a generic version will fight the shape of what you're building. Then architect on open standards so that when your scale changes and the line moves, you can move with it instead of getting trapped by the vendor you picked when you were ten times smaller.

That's the entire framework. Not build versus buy. Commodity versus product, drawn deliberately, on standards you can walk away from.

Where's the line drawn in your stack right now, and is it still in the right place for the scale you're at today? That second question is the one most teams haven't asked recently enough.

FAQ

Should I build or buy authentication?

Neither as a pure choice. Every real identity architecture is a hybrid. The useful question is which parts of identity are commodity (password hashing, OAuth/OIDC flows, MFA delivery, session management) and which are your product (authorization model, user model, onboarding). Buy the commodity layer because owning it is cost and liability with no differentiation. Own the product layer because a vendor's generic version will constrain your roadmap.

How much does it cost to build authentication from scratch?

Building passwordless and passkey auth alone typically takes 800+ engineering hours and three to six months to reach production, before ongoing maintenance. Because underlying standards like OAuth 2.1 and MCP-based agent auth are still evolving, custom builds also require continuous engineering time to track spec changes. Industry analysis suggests fewer than 5% of engineering teams should build auth from scratch.

Is self-hosting Keycloak actually cheaper?

Only at the right scale. Keycloak's license is free, but operating a production high-availability cluster starts around $1,250/month in infrastructure, and three-year total cost of ownership analyses put it near $199,000 to $211,000, with roughly $142,000 in operational labor. It also makes every Keycloak CVE your responsibility to patch. Self-hosting trades per-user fees for a standing commitment of about half to one full engineer, which pays off at high volume and hurts small teams.

When does full custom authentication make sense?

Essentially only when identity is your actual product: you're building an identity provider, an authorization engine, or a security product whose value proposition is how it handles auth. In that case auth is your product layer, not your commodity layer, and building is correct. For everyone else, full custom means paying enormous engineering costs to re-solve problems inexpensive vendors already solved.

Why does the build vs buy debate keep coming back every year or two?

Because the commodity-versus-product line moves as you scale. Full SaaS CIAM is right at 5,000 users and may be wrong at 5 million, when per-user pricing can exceed the cost of self-hosting. The original decision wasn't wrong; the right answer changed. The defense is to build on open standards (OIDC, OAuth, SAML) so moving the line later is a configuration change rather than a rewrite.

Deepak Gupta is a serial entrepreneur and cybersecurity researcher who founded LoginRadius and scaled it past a billion users. He now builds AI and identity products and writes about security and B2B growth at guptadeepak.com.