Every new product hits the same fork early on: how do users sign in? It looks like a small decision, tucked in among bigger questions about architecture and data model. It rarely stays small. Authentication touches almost every other part of the system – session handling, permissions, billing, compliance, support tooling – and the choice you make in week two tends to still be there, unchanged, three years later. Ripping it out and replacing it once real users and real data depend on it is a project in its own right.
The build-or-buy question here isn’t really about whether you can write a login form. Any competent developer can. It’s about what a login form quietly implies once it’s live.
What “buy” actually gets you
Managed identity providers – Auth0, AWS Cognito, Clerk, Ory, and others – sell more than a login screen. What you’re really paying for is the accumulated edge-case handling that only shows up after an authentication system has been attacked, abused, and stress-tested by thousands of unrelated products:
- Password hashing that gets updated as attack techniques improve, without you having to track the research
- Multi-factor authentication, including the recovery flows for when a user loses their second factor
- Session and token rotation, refresh handling, and revocation across devices
- Social and enterprise sign-in (OAuth, SAML, OIDC) without you maintaining a connector per provider
- Breach detection – credential stuffing, leaked password lists, anomalous login patterns
- Audit logging in a format that will actually satisfy a customer’s security questionnaire
None of this is exotic engineering. It’s just a lot of unglamorous, security-sensitive work that has to be right every time, not most of the time. Buying converts that ongoing liability into a monthly line item and someone else’s on-call rotation.
Why the build option is deceptively appealing
The first version of a homegrown auth system is genuinely quick to write: an email and password field, a hashed row in a database, a session cookie. It works in the demo, it works in the first few weeks of real usage, and it costs nothing per user. That early experience is exactly what makes the decision risky – the cost isn’t in the first version, it’s in everything that gets bolted on afterwards.
A short, incomplete list of things that show up later, usually driven by a specific customer request rather than planning: “can we add Google sign-in”, “our biggest customer needs SAML for their SSO policy”, “we need to force a password reset for one compromised account without logging everyone else out”, “legal wants an export of every login event for this user, tied to a subject access request”. Each of these is solvable on its own. Handled reactively, one at a time, inside a system that wasn’t designed for them, they add up to a permanently fragile core module that nobody enjoys touching.
Where buying is the wrong call
The case for building isn’t purely defensive – there are situations where it’s the more sensible engineering choice:
- Data residency and sovereignty requirements that a given vendor’s regions don’t satisfy, particularly relevant post-Brexit for UK public sector or health-adjacent work.
- Genuinely simple, closed systems – an internal tool used by a dozen employees behind a VPN doesn’t need the same machinery as a public-facing product with self-service signup.
- Pricing that breaks at your scale. Most identity providers charge per monthly active user. That model is comfortable at ten thousand users and can become the single largest line item in your infrastructure bill well before a million. Model this early, not after you’ve integrated.
- Unwillingness to hand a third party your user table. Some products – anything handling health data, financial records, or safeguarding-sensitive information about children or vulnerable adults – warrant keeping identity data in infrastructure you control outright, even at the cost of more engineering effort.
The middle ground: build on standards, not from scratch
The build-or-buy framing suggests only two options, but there’s a third that’s often the right answer: adopt the open standards (OAuth 2.0, OIDC, SAML) and run the implementation yourself using an established open-source project – Keycloak, Ory’s stack, or similar – rather than either writing the protocol handling from first principles or handing the whole thing to a SaaS vendor. You get to keep the data in your own infrastructure and avoid per-user pricing, while still relying on code that has been reviewed and hardened by a wider community than your own team. The trade-off is operational: you’re now responsible for patching, uptime, and backups on a system that, if it goes down, takes your entire product with it. That’s a fair trade for some teams and the wrong one for others, depending on whether you already run infrastructure of that kind.
Across the products we’ve built at Nordic Byte – a rota and absence platform used by HR teams, an IoT fleet manager with device-level credentials as well as user logins, a personal finance app handling Open Banking connections – the right answer to this question has been different each time. The rota platform, dealing with ordinary staff accounts, made sense on a managed provider. The finance app, given what it touches, made a stronger case for keeping identity data in-house. There isn’t a single correct default; there’s a set of constraints specific to what the product does and who’s trusting it with their data.
A decision checklist
Before committing either way, it’s worth answering these directly rather than going with whichever felt more familiar to whoever wrote the first prototype:
- Will any customer, current or realistically anticipated, require enterprise SSO (SAML/OIDC) within the product’s first two years?
- What does the identity provider’s pricing look like at ten times your current user count, not your current one?
- Does the data you’re protecting fall under a regulatory regime (health, finance, children’s data) that constrains where and how it can be stored?
- Do you already operate infrastructure reliable enough to run a self-hosted identity service, or would this be your team’s first piece of always-on infrastructure?
- If the answer is “buy”, can you export your users and their credentials cleanly if you need to leave the vendor later?
None of these questions has a universally right answer. What they share is that they’re cheap to answer now and expensive to answer after a customer’s security team has already asked them on your behalf.