Every client asks for "secure login." Almost none of them mean the same thing by it. A healthcare platform means something has to survive an audit. A B2B tool means someone's IT admin needs to log a new hire in without a support ticket. A consumer app just means "don't make people think." Authentication looks like one problem from the outside. Up close, it's a different problem every time — and treating it like a checkbox is how teams end up with logins that are secure on paper and painful in practice.
Good authentication isn't the strongest option available. It's the right one for who's actually logging in.
01We start with who's logging in, not what's trendy
Passkeys are having a moment, but they assume a modern device and a steady connection — not always true. A field team on shared tablets needs something offline-first. An internal tool for five people needs less ceremony than a public app with a million logins. Before we touch a login screen, we ask who's actually using it — the fanciest factor is worthless if it locks out the people it's meant for.
02Compliance decides more than we'd like
Some of the biggest authentication decisions aren't ours to make — the client's industry makes them. Healthcare and finance clients often can't let session data leave a region, and need every login attempt logged, not just the successful ones. A regulator cares less about the tech than whether you can prove, months later, who accessed what and when. We design the audit trail before we design the login button — retrofitting compliance later is far more painful.
03We build around what's already there
Very few clients start from zero. There's usually an existing directory, an Azure AD or Okta setup, a legacy system nobody wants to touch but can't retire either. New authentication has to slot into that reality — supporting SSO where it exists, migrating credentials without a mass password reset, never locking out the old system mid-rollout. The best authentication work is often invisible: nobody notices the login that already worked.
04Built for this client, still theirs to walk away with
Even when authentication is built for one client's exact requirements, the same rule applies as everything else we ship: it has to be theirs to keep. No proprietary format trapping their user data, no dependency only we can maintain. Bespoke doesn't have to mean locked in — it just means it was built for them, on their terms, and keeps working long after we've handed it over.
Working through your own authentication requirements and want a second opinion? Start a project