Nobody Plans to Build an Identity Platform. Yet Almost Every SaaS Company Does.

Somewhere in your codebase there's a folder called auth. It probably started as a weekend's work — a users table, bcrypt, a session cookie, maybe a JWT if whoever wrote it had opinions. Nobody scheduled a design review for it. It wasn't on the roadmap as "build an identity platform." It was a login page, and login pages are not supposed to be interesting.

Five years later, that folder is thousands of lines across a dozen files, three engineers privately consider it cursed, and it is quietly the single most expensive piece of the product to change. Nobody decided to build an identity platform. It happened anyway, one enterprise deal at a time.

The two-week login that became a three-year project

The first version is always fast to build, because it only has to solve one problem: let a known set of users type a password and get in. Two weeks, maybe three if you're doing password resets properly. It ships, it works, everyone moves on to features that actually differentiate the product.

Then the product starts selling. And the first few deals are easy — a startup buying from a startup, both sides using email and password and not asking hard questions. But at some point a deal shows up with a security questionnaire attached, and questionnaire item one is: "Do you support SAML SSO?"

You don't. So you build it, for that one customer, on a deadline, because the deal is worth more than the engineering quarter it costs. Six months later a second enterprise customer asks the same question, except they run Okta and the first one ran Azure AD, and your SAML implementation quietly assumed there was only ever going to be one identity provider. A third customer's security team wants to know if you support SCIM for automated deprovisioning, because their last vendor kept an ex-employee's account active for four months after they left. A fourth wants enforced MFA. A fifth wants configurable session timeouts because their compliance framework specifies a maximum idle duration.

None of these requests are unreasonable. Each one, in isolation, looks like a two-sprint feature. What's easy to miss is that they don't compose — SAML for one customer and OAuth for another and a legacy password flow for everyone else all have to coexist in the same login screen, the same session model, the same audit log. The system that made sense as a single-tenant login page starts accumulating branches, feature flags, and tenant-specific configuration that nobody fully holds in their head anymore. The two-week project didn't get bigger by 10x. It got wider, and width is what makes something unmaintainable.

The identity feature explosion

If you list out what a login system for a real B2B SaaS product eventually needs to support, it stops looking like "auth" and starts looking like a product category:

• Password auth, with the actual hardening that implies — hashing, breach-list checks, lockout policy
• Multi-factor authentication: TOTP, SMS (which you'll regret), push, and increasingly passkeys
• SAML federation, per customer, each with its own IdP quirks
• OIDC/OAuth for the customers whose IdP prefers it, or for your own API clients
• SCIM provisioning and deprovisioning, so identity lifecycle is managed from the customer's IdP, not yours
• Role and permission mapping that has to reconcile your app's model with whatever the customer's IdP hands you in a token
• Session management: timeouts, concurrent session limits, forced logout on password change
• Audit logging that satisfies a SOC 2 auditor, not just a debug log
• Account recovery flows that don't become the easiest way to take over an account
• Admin tooling so a customer's IT team can self-serve their own SSO configuration instead of filing a ticket with you

Each item on that list is its own small domain, with its own edge cases and its own standards body. None of them were in the original two-week scope. All of them show up eventually, usually one enterprise logo at a time, and usually with a deal attached that makes "no" expensive.

Why embedded identity kills delivery velocity

The real cost isn't any single feature. It's what happens to the rest of the team once auth becomes load-bearing.

Every feature elsewhere in the product now has to ask "what does this look like across our different auth methods and tenant configurations?" A new admin page needs role checks that behave consistently whether the user came in through SAML, OAuth, or a password. A new API endpoint needs to work for both session-based and token-based clients. The engineers who understand the identity code well enough to touch it safely become a bottleneck, because nobody wants to be the person who breaks login for a paying enterprise customer at 2pm on a Tuesday. Onboarding new engineers gets slower because the auth folder is the one part of the codebase that requires tribal knowledge to navigate.

And the risk profile is asymmetric in a way that discourages investment. Ship a bug in a reporting feature and a customer files a ticket. Ship a bug in session validation and you've potentially given one tenant's users access to another tenant's data. That asymmetry makes teams conservative about refactoring the identity code even when everyone agrees it needs it, which is how a "temporary" SAML implementation from three years ago is still running in production, untouched, because nobody wants to be the one who breaks it.

This is the part that rarely makes it into the original build-vs-buy conversation: the cost isn't the identity code itself. It's the tax it puts on the velocity of everything built around it.

Why standards matter

It's tempting to look at the growing pile of SAML assertions, OAuth grant types, and SCIM schemas and conclude that identity people love complexity for its own sake. The opposite is closer to true. Almost every piece of that complexity exists because an earlier, simpler version of the same idea got exploited, and the standard was patched — sometimes literally, sometimes by a successor standard — to close the hole.

SAML's XML signature handling is notoriously fussy because XML signature wrapping attacks let attackers forge assertions against systems that verified signatures carelessly. PKCE exists because authorization codes could be intercepted on mobile and single-page apps that couldn't safely hold a client secret. State and nonce parameters exist because without them, OAuth and OIDC flows are vulnerable to CSRF and replay. Refresh token rotation exists because a static, long-lived refresh token is a permanent skeleton key if it ever leaks.

None of this is arbitrary, and none of it is something a competent team is likely to reinvent correctly from first principles while also shipping product features. That's the actual argument for standards: not that they're elegant, but that they're the accumulated scar tissue of an entire industry's mistakes, available for free to anyone willing to implement them correctly. The alternative isn't simpler. It's the same set of problems, discovered the hard way, one at a time, on your own production users.

Build vs. buy isn't the right question

Framed as "build vs. buy," this becomes an argument about engineering pride, and engineering pride usually wins, because building it feels more in control and buying it feels like an admission that your team can't handle it. That framing is a trap. The real question isn't whether your engineers are capable of implementing SAML correctly — most good engineers are, given enough time. The question is whether implementing and then indefinitely maintaining SAML, OAuth, SCIM, MFA, passkeys, and their interactions is the best use of a scarce engineering team relative to the product you're actually trying to build.

Identity has a specific property that most application features don't: it's never done. A pricing page ships and then mostly sits still. A login system has to keep up with new attack techniques, new protocol versions, new compliance requirements, and new customer IdPs indefinitely, for as long as the product exists. That's not a feature you finish. It's closer to infrastructure you operate — which is a different kind of commitment than most feature work, and worth evaluating as one.

When embedding identity is perfectly acceptable

None of this means every team should immediately rip out its login system and bolt on an external identity provider. If your customers are consumers or small teams, if SSO and SCIM aren't things your buyers actually ask for, if you're pre-product-market-fit and the two-week login is genuinely serving you fine — building and owning it is the right call, and probably will stay the right call for a while. Complexity that hasn't shown up yet isn't complexity you need to pay for in advance.

The pattern to watch for isn't "we have a login page." It's the moment identity requirements start arriving from outside your own roadmap — driven by customer security teams, procurement checklists, and compliance frameworks instead of your own product decisions. That's the signal that you've stopped building a feature and started operating a category, whether you meant to or not. At that point the honest question isn't whether you're capable of building an identity platform. It's whether building one was ever the plan — and if it wasn't, whether it's still the best use of the team you have.