I was thinking about this because it sounds like such a small product decision, but I don t think it actually is.

Someone signs up with Google. Six months later they are on their iPhone and tap Sign in with Apple. Same person, different identity provider. And if they use Hide My Email, you may not even get the same email address.

So what should the product do?

Creating a new account feels wrong because now their history, billing, settings, or subscription can end up split across two profiles. But automatically linking accounts based on email also feels risky, because now you are assuming that matching email addresses are enough proof that both identities belong to the same person. And then Apple makes it even messier because the emails may not match at all.

Every fast-growing company seems to have the same quiet migration story. They picked an auth tool early because it was fast to set up, free enough that nobody really had to think about it, and honestly, it was probably the right call at the time. Nobody is evaluating whether a login system can survive an enterprise deal when they are 10 people and just trying to ship the product.

Then the growth actually happens. The company gets to 50 employees, maybe starts selling to bigger customers, and the first serious enterprise prospect sends back a procurement checklist with SSO sitting somewhere near the top, non-negotiable. That is usually when you realise SSO lives on a tier that costs more than the entire tool used to cost you, or in some cases is not even available anywhere near the plan you are already three years deep into. So now you have a migration project nobody planned for, timed exactly when the company can least afford the distraction. And auth migrations are not exactly like swapping out an analytics tool. They touch active sessions, integrations built against the old system, login flows, permissions, and every customer already using the product, all while the deal that triggered the panic is still sitting in procurement waiting for an answer.

I don't really think this is a story about any one vendor being careless. It feels more structural than that. Tools built to be generous and fast at the small end tend to hit a hard ceiling right when a company starts needing enterprise features. And tools built enterprise-ready from day one usually come with an onboarding process and cost that a five-person team has absolutely no reason to take on early. There is a weird gap in the middle where very few products seem designed around the assumption that the same company might actually grow from one end to the other while staying on the same stack.

Has your team already hit that wall, or are you still early enough to see it coming before it costs you a deal?

you want your AI agent to work without friction. you also want your platform to be secure. but here's the thing, those two goals are in direct conflict the moment a non-human actor shows up at your door.

most platforms weren't designed with agents in mind. so when an agent tries to access something, it either borrows a human's credentials which gives it too much, or gets blocked entirely which defeats the purpose.

you hit logout. the app says you're out. but somewhere, on another device, on another app using the same login, your session is still alive.

most users assume logout means logout everywhere. it doesn't. it usually means logout from this tab, on this device, right now. everything else keeps running until the token expires.

most auth setups issue a JWT and move on. the token is valid, the user is in, done.

but here's the scenario nobody wants to think about: the token gets stolen. maybe a compromised device, a leaked log, a man-in-the-middle on an untrusted network. doesn't matter how. it's out there now.

and it's valid for another 58 minutes.

most of the conversation around AI agents is about what they can do. faster, smarter, more autonomous. but i've been thinking about the other side of that question.

when you're building with agents, at some point you have to draw a line. this agent can read but not write. it can suggest but not send. it can book but not pay. somewhere, someone made that call.

Passkeys are objectively better than passwords.

Phishing-resistant, nothing to forget, nothing to breach, no password database to leak. the case for them is pretty airtight. and yet most products still default to email and password. most users have never set up a passkey. most developers have never shipped one.

One of the teams using MonoCloud made a decision most founders are too nervous to make: they turned off passwords completely.

no fallback, no 'or create a password instead.' passkeys by default, magic link as the backup, done.

here's what actually changed after they did it.