You can build your own authentication system in a day, and it runs for years. The real cost shows up later, the day your business changes. Lessons from dozens of B2B interviews.
Authentication looks like something you can knock out yourself. Email, password, hash it, compare on login. How hard can it be to build your own authentication system?
You can. That's the trap.
We've talked with dozens of teams about the auth they built themselves. Most came to us for the same reason: it was holding the business back.
Different industries, stacks, and sizes, but the same ending. The auth they built had become a debt the team was carrying.
The strange part is that it never shows up as an outage. The system logs people in and runs fine, until one business change blocks the road: a security review, the first enterprise customer, an acquisition, a feature spanning two products.
Last week it was "fine." Then the next thing on the roadmap is stuck behind it.
The biggest mistake with homegrown auth is treating it as a feature. You can write it on day one. But once real traffic runs through it, it tangles with your users, orgs, and permissions.
Authentication isn't a feature. It's identity infrastructure.
Every homegrown auth system starts the same way. Take an email and a password, hash it, store it, compare on login. Forty lines of code, clean and done.
The trouble starts after launch. Bots hammer the signup endpoint, so you add rate limiting, a CAPTCHA, device fingerprinting. SMS codes stop going out one morning, so you bolt on retries and a daily cap. Then come the harder parts: secure password reset, MFA and its recovery flow, sessions and refresh tokens, and a permissions model that's a lot more than an is_admin boolean.
None of these is hard on its own. Each fits in a sprint. But every time you ship one, you're answering a bigger question on behalf of the product.
Stack those answers up and you get the identity model your product now silently assumes is true: who counts as a user, whether one person can belong to several orgs, how an enterprise customer's own identity system plugs in, and how access gets pulled back when someone leaves.
Every feature you write afterward treats those answers as given, and the longer it runs, the harder they are to change.
We saw this play out at one company: a vertical B2B SaaS, twenty years in business, serving brick-and-mortar operators. They built their own auth more than a decade ago, with a separate login per customer and permission checks written straight into the business modules. It was the reasonable call at the time.
Twenty years later, they wanted something that sounds small: one unified login page, with email as the username. It wasn't a page change at all. Those checks had spread into hundreds of modules, and unifying login meant touching the user model, the org model, credential migration, and every permission boundary. Nobody wanted to sign off on that, so it dragged on for years.
When they wrote that first login page, it looked like a feature. What it left behind was a whole identity model.
In fairness, homegrown auth usually runs for a long time. It logs people in, refreshes sessions, and carries the daily business for years. Its complexity piles up slowly, never all at once, and you handle it bit by bit while feeling like you've got it under control.
But staying "enough" often just means the business hasn't hit the wall yet. When it does, the problem usually isn't auth itself. The business next to it changed, and "enough" turns into "in the way" overnight.
The situations below show up for most products as they scale. They look different, but underneath they're the same thing: the business moved forward, and the old identity model can't keep up.
The scenario: a customer wants to log in with their own IdP, and your auth system has no concept of "someone else's identity provider."
The first real enterprise deal lands, and procurement sends a requirements doc. First it's SSO through their Microsoft Entra or Google Workspace. Then it's both SAML and OIDC, because the next customer runs something else. Then it's SCIM, to provision and deprovision employees automatically.
Every customer's setup is different: different protocols, field mappings, certificate rotation, and ways their org structure maps onto yours.
And almost none of that work carries over. The next customer brings a different IdP and a fresh config, and most of it starts again. SSO isn't a feature you build once. Every big customer you sign, you build it again, and the cost only grows with the customer count.
Auth has stopped being "let users log into your product." It's "let your product plug into the customer's identity system." Two completely different jobs.
We saw one company where the entire SSO setup was done by hand, and exactly one engineer understood it end to end. When he was around, customers went live. When he took time off, sales and onboarding queued behind him. When he left, the knowledge walked out with him.
None of this was on the table the day they decided to build their own auth.
The scenario: your identity data started out fragmented, split by org and by product, and as the business grows you start needing one unified identity.
The twenty-year company above hit this when it tried to unify login, and the same shape shows up across products. We worked with a platform that had nine products, all from acquisitions, each carrying its own auth and user store.
An acquisition doesn't merge those for you. Every product you buy, you inherit another auth stack, and nine in parallel takes real headcount just to maintain.
The questions pile up. Is the same person one user across products A and B, or two? How do you line up the same customer org in both? How do you authorize a cross-product feature? When an employee leaves, how do you revoke access across all nine at once? And where do you audit any of it?
Not one of the nine is broken. Put together, they're a wall.
"Unify identity" sounds like a feature. In code, it means redefining the most foundational thing there is: what counts as one user and one org. Almost every feature sits on the old definition, so moving it moves the whole layer above.
The scenario: it's no longer just people logging in through a browser. Now agents, command lines, and scripts all claim to act for some user, while your auth knows only one thing: a person logging in on a page.
An agent needs to call your internal tools for a user. An MCP server needs to expose protected resources safely. A CLI needs to reach account data with no browser.
All three hit the same questions: which user does this request act for, which resources can it touch, who is the token issued to, what's its scope, how do you revoke it, and do you log the user or the agent?
The old system never built the mechanisms these clients need. MCP relies on OAuth for authorization. A CLI either goes through an OAuth login or carries a personal access token that stands in for a person and can be revoked anytime. None of that was made for a login page.
If your auth was designed around one person logging in on a page, now is when you have to handle a client showing up to act on that person's behalf.
None of the situations above is "auth crashed." The system still runs. Each looks like a small feature, and the moment you start, it turns into product strategy, data migration, and customer delivery work.
MFA is the clearest case. On the surface it's "can we verify once more after login."
Two steps in, it's: which orgs and users do you force it on, can an admin enforce it for members, do sensitive actions like changing payment info or exporting data need a re-check, how do you generate and reset recovery codes, can support reset them, and does an SSO user's MFA belong to you or to the customer's IdP? Adding MFA means adding a whole layer of security policy.
"Just sync some users" is the same story: behind it sits a string of decisions about onboarding, offboarding, and cross-org membership, each assuming your user and org models were designed right from the start.
The more features you add, the more you're maintaining an identity product inside your own product. The first version is cheap, a few engineers and a few weeks. But you feed it year after year.
The most common reason to build your own is cost, and it isn't naive.
One membership organization we interviewed ran the numbers five years ago. They had about a hundred thousand members, but only a few thousand logged in regularly. Vendors charged by total member count, the quote blew past the budget, and building it themselves came out cheaper. For that year, it wasn't the wrong call.
Five years on, the math had flipped. Maintaining their own login and keeping it secure had already cost more than buying would have.
In year one, the invoice you save is visible and the engineering time is not. By year five, the avoided invoice is the same number, but the engineering time has become roadmap delays, security debt, and maintenance nobody wants to take over.
So building your own auth isn't free. You just never get an invoice that says "authentication subscription." You pay it in person-months, slipped deadlines, rework, security debt, and the engineering attention you could have spent on the core product.
That engineer hand-maintaining SSO isn't a one-off. Run homegrown auth long enough and the critical context settles onto one or two people: which customer is configured how, which field you must not touch, why a past migration was done a certain way. It rarely makes it into docs. It lives in someone's head.
When he's there, delivery moves. When he's not, the enterprise pipeline stalls, and you find that your most important infrastructure has no owner, only "the person who knows."
Some teams go further and build customers a full self-serve SSO configuration platform. It sounds mature, until you ask how many customers it serves. We saw one with 1.5 million monthly actives running a whole system like this for barely a dozen customers.
You thought you were building a feature. You were building an internal product, with the cost spread across a dozen customers. If identity is your business, that's worth it. If not, it's the hidden bill in its purest form.
Back to that twenty-year vertical SaaS. They're not weak engineers. Keeping an industry product alive for twenty years is exactly what tells you they know their customers well.
That's the whole problem. Put it bluntly: do you want them hand-maintaining each customer's SSO and pulling twenty years of permission logic out of hundreds of modules, or going deeper on the industry software itself?
This isn't engineering perfectionism. It's resource allocation. If you build bill pay, vertical SaaS, a membership portal, or operations software, no customer pays you a cent more because you wrote your own OAuth server.
One bill-pay team we interviewed put it plainly: their homegrown IdP was fine, but it's a strategy call. Don't write much code on auth. Save the energy for making bill pay the best it can be, and use the most proven auth on the market for the rest.
Auth has to be reliable. But "reliable" isn't the same as "built by you." Your database, email delivery, and cloud all have to be reliable too, and a mature team doesn't assume something belongs in-house just because it's important.
For most products, auth is a core dependency, not a core differentiator. Unless identity is your business, running an identity product inside your product usually isn't a moat. It's a long-term drain on resources.
It's easy to slide into an extreme: never write auth code. That's wrong too.
At some stages, building your own (or half of it) makes complete sense: internal demos, very early prototypes, one-off validation projects. And if your business has highly specific fine-grained authorization that off-the-shelf platforms genuinely can't express, keeping that part in-house, while an external platform handles authentication, sessions, SSO, MFA, and the user directory, is perfectly reasonable.
Just watch the POC slope. We've seen the typical path: two developers spend six to eight months on a prototype to integrate with an external system. The approach isn't bad. In their own words, the thing is good. It just was never meant to carry scale.
And a POC is the easiest thing to harden into long-term architecture. Six months later it's "the current solution," two years later "the legacy system," five years later "infrastructure we can't touch." The best time to exit homegrown auth usually isn't after it breaks. It's before it turns into the foundation.
So the line is this: the question isn't whether you've written a line of auth code. It's whether you've taken on a generic piece of identity infrastructure and kept it on your own team for the long haul.
Build edge capabilities yourself. Be careful about the core identity layer. And don't, without noticing, build yourself a full CIAM platform.
If you decide not to write it yourself, the next question shows up: whose do you buy, and how do you pick?
Most mature solutions already cover the features: SSO, MFA, multiple orgs, unified login, agent access. So the real difference usually isn't the feature column.
What's easier to overlook, and more worth comparing, are the points below. They're facets of one thing: don't climb out of the few thousand lines you wrote yourself only to get locked into another system you can't leave.
Full disclosure: Logto is the auth product we built against exactly these four points. It's open source, self-hostable, and also offered as a managed Cloud: use Cloud for zero maintenance, or self-host the open-source version for full control, and the day you want to move out, the door stays open.
Sign-in, MFA, SSO, and RBAC work out of the box on standard OIDC, and billing follows tokens, so you pay for what you use.
There are other mature options out there, and auth was never a question with a single right answer. If you're evaluating, I wrote a whole piece on how to choose an auth solution you can use.
Building your own auth is usually reasonable on day one. The catch is that it grows into infrastructure later.
Every step the business takes exposes it again: enterprises want SSO, security wants MFA, the product wants unified login, multiple products need to connect, AI agents want to reach resources for a user. Behind each tiny-looking feature sits a string of policy questions, and feeding it over the years eats the engineering time that belonged in your core product.
This bill doesn't arrive on day one. It usually shows up years later. By then you can finally see it: that login page you wrote back then was already identity infrastructure that would run through the product's entire life.
Auth probably isn't your core business. The sooner you see that, the sooner you can put your time, energy, and resources back into the product you're actually building.
No. Early demos, internal tools, one-off validation projects, or highly specific fine-grained authorization that off-the-shelf options can't express can all be a fit. What to avoid is taking on a long-term, generic piece of identity infrastructure without realizing it and parking it inside a business team's maintenance scope.
Authentication answers "who are you." Authorization answers "what can you do." In a real SaaS the two are hard to separate: users, orgs, roles, permissions, sessions, token claims, and audit logs all weave together. So when you replace an auth system, you can't just look at the login page.
Because it means making your product plug into the customer's own identity system. Different customers use different IdPs, protocols, claim fields, certificates, and org mappings. Getting the first one connected doesn't mean the rest are copy-paste. More often, it becomes hand-work only one engineer understands.
Yes, though a single hard cutover usually isn't the way. Migrate in layers: put new sign-ups, logins, and enterprise SSO on the identity platform first, and migrate existing users on their next login. Keep a rollback path and audit logs throughout, so the migration never becomes irreversible.