Building User Authentication - ProductFTW #46
You hate it, you need it, you move on
Most user experiences today start the same way: login. Outside of a few truly read-only corners of the internet, nearly every product assumes a logged-in user. This means that when you’re building something new, the first real feature you build — whether you realize it or not — is authentication.
That wasn’t always the case. Early websites were wide open. You just showed up and read what was there. Take my own site, for example. Here’s an awkward version of it from 1997 via the Internet Archive. No login, no tracking, no cookies, just teenage me oversharing on the internet.
Fast forward to today: my personal site, matthewgoldman.com, runs on Ghost, the same platform powering this newsletter. It’s still mostly static (90% of its traffic is about spoonerisms, weirdly enough), but guess what? You can log in! There’s a full backend with user roles, an admin interface, and role-based access control. Even when you don’t need auth, it’s lurking in the background, quietly powering the modern web.
It’s not just me. Early versions of major publications like The New York Times didn’t require login either. But as soon as content personalization, saved preferences, and subscription models entered the picture authentication became table stakes.
This evolution became really clear to me in 2014 when Bankrate, Inc. acquired my startup, Wallaby Financial. At the time, none of Bankrate’s websites allowed consumers to log in or manage data. No personalization, no dashboards, nothing. Wallaby’s biggest strategic asset wasn’t just credit card recommendations: it was a full user-authenticated experience with custom data and personalization. That was a big deal.
When we started Wallaby in 2012, there were libraries to help you build authentication, but no real services. You had to roll your own. We used a Java OAuth library, and it was miserable. Auth is one of those features that seems simple on the surface, almost boring, even. It’s required in nearly every app. It’s conceptually well understood. And yet it always causes problems.
Worse, nobody wants to own it. Auth lives in this awkward space: critical to your product but rarely a core differentiator. It’s too risky to ignore and too annoying to prioritize.
Today, we’re lucky to have services like Stytch, Auth0 (now part of Okta), and built-in options from cloud providers. In theory, you can just plug one in and move on. But in practice? There’s always some weird edge case that the service doesn’t support. Do you want to add a secondary email? Tweak session expiration? Auto-logout after 15 minutes of inactivity? Suddenly you’re writing custom code again. Back to engineering, it goes.
I’ve yet to work with a team that wants to outsource auth. Everyone thinks it’ll be easier to build it themselves, but most of them regret it. Teams burn weeks (sometimes months) trying to get it “just right,” only to end up with bugs, brittle logic, and poor UX.
When you’re early—pre-product/market fit, pre-scale—your job is to move fast and focus on your product's real differentiators. Authentication probably isn’t one of them.
My advice? Use a service. Make it someone else’s problem. Save your energy for the things that actually move the needle.
About ProductFTW
ProductFTW is a biweekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.
Part of the Fintech Product Management Field Guide — ProductFTW's writing on what makes building card, payment, and banking products different.