This is a screenshot of the first few commits for Lumastic - a product and company I spent 4 years working on. Why do you think I cringe a little when I look at it? Well, other than the fact that I spelt field wrong and have two commits to get rid of console.logs.
I cringe because the thing these commits do is give the user the ability to Login and Signup for an app that does nothing else. Thinking about this now, it's obvious that starting with these two features was a mistake for so many reasons.
But starting with authentication (auth) is a mistake I see even experienced founders and product engineers make constantly. So, in this article, I want to explain why I no longer start with auth when building new apps and what I do instead.
Let's start by admitting that at the beginning of a product's life...
🙈 Auth is fake work.
How many product landing pages have you seen where, "Can sign up and login" was one of the key highlighted capabilities? The answer is none; because auth isn't an action user's want to take.
Auth is an action we make them take in order to increase the integrity and security of data in our applications. Which means that before the app is useful in some other way, we don't need auth. So, why is it usually the thing we jump to build first?
Well, because it's a known and solved problem. It's a common feature with explicit requirements and infinite guides on implementing robust solutions. And because of this clarity, building it gives us the feeling that we've built something right. Starting with auth makes us feel like we're making progress.
However, building auth before we need to is a waste of time; it's fake work. It's procrastination from tackling the harder problems in our projects; the ones that our users actually care about; the ones that makes our apps unique and useful; the ones with unclear answers that we're far more likely to get wrong.
But tackling these difficult, unknown problems is actual progress. Because making attempts at answering the hard questions is how we start learning what our customers really want. We don't learn anything about our customers by building auth.
Plus, although auth is a known problem with a clear solution, we often underestimate the amount of work it takes to implement. Although it seems simple...
😅 Auth takes more time than we think.
The deceptive thing about auth is that it's not just one feature. Take signup and login for example. Although related, they are really two completely separate actions the user takes within our apps. But sadly, one really isn't that useful without the other so we have to build them at the same time.
And this compounding effect doesn't stop with signup and login. Logout, forgot password, reset password, account information, update email, etc. - all of these features need to be implemented in order to create the robust auth experience user's expect from modern applications. Suddenly, what often seems like an easy win at first glance quickly turns into a huge time suck.
Using services like Auth0, Cognito, or Auth.js can help us abstract a lot of the implementation complexity away from these features, but they aren't magic. It still takes a fair amount of time to setup all of the branding, callback URLs, and testing abstractions that allows us to create a robust UX and DX when using these third party APIs.
So, to me it's best just to leave auth out of the picture until we really need it; and for some apps, we might never need it.
🤷🏻♂️ Auth isn't always necessary.
Auth is such a standard feature that we often assume it's a requirement for all apps. Obviously, it's not. There are tons of applications that users can get immense value from without needing to create an account.
Basically, unless our app's core value requires features of authorization, we don't need to build authentication. We can know if our app's core value rests on authorization by asking two questions:
- Must the user be able to access their data from multiple devices?
- Must the user be able to share data with other users on other devices?
"Must" is the key word here. "Must" means, "without this, the app isn't valuable". I think there are very rare occasions where the answer to those questions is an immediate yes. Because usually, when we launch our initial release, we're launching to no one but ourselves. If we're lucky, we'll have a group of 5-10 early adopters. And in both of those cases, we can usually get by without auth at launch.
And if we do need some version of authorization at launch, we can often mimic those features with a few hacks. A long running cookie on the device is a great way to identify users without needing to build a full login and signup system for credentialing.
Sure, it presents some manual work if a user accidentally clears their cookies, but it allows us to ship something to production faster and start gathering real customer feedback. Plus, while we're learning from our user's, we could work on hooking up Auth0 behind the scenes. By working this way, we essentially treat auth like any other feature; we wait to build it until there is a reason to build it.
Now, obviously this isn't possible for every app, every product, or every customer base - especially those that deal with sensitive data or customers with strict requirements. But for consumer apps where we're launching to an intimate, trusted group of early adopters, I think this strategy works really well.
So, now that I've talked about why we shouldn't start with auth when we start new projects, it begs the question...
✨ Where should we start?
Well obviously, after we've had an idea for a product, we should not just jump into writing code. We should map out a breadboard diagram and maybe do some fat marker sketches to help us identify our product's core value prop. Checkout this article for more info on that process.
Those two prototyping tools should give us a good indication about where to begin building. But if it's still ambiguous, we should try to identify what pieces of our product directly solve what I call a "3D problem". 3D problems are dire, difficult, and doable.
"Dire" means that, for our customers, these problems feel serious and urgent. They don't have to be life or death, but they do present real stakes. These are the problems that make our customers feel like their hair is on fire. We want to focus on dire problems because those with dire problems are willing to try even the worst solutions; and our products usually are the worst solution in the beginning.
"Difficult" means that the problem feels challenging to solve; it scares us a little. That slight fear of the problem is a good thing because it will deter others from tackling it. Picking problems outside of our comfort zones is when we grow the most and have the best chance of building something truly unique.
Finally, "doable" problems are those that we believe we have the skills and knowledge to solve. Despite the difficulty, we have the naive delusion that we could actually make it work. This balance between optimism and pragmatism is what keeps us engaged, creative, and having fun while moving fast and being able to ship things quickly.
By using this framework, we are far more likely to start our products focused on making real tangible progress on the problems that matter. And I hope you can see now that 99.999% of the time, that most important problem is never auth.
👋 What do you think?
I hope you enjoyed this article! I write to share what I've learned and spark conversations that help me learn from others. I know some of the ideas in this article are controversial. So, I'd love to hear what you think of them on Twitter or LinkedIn. You can also email me if social media isn't your thing.
Also, if you want to get notified the next time I post an article like this, you can sign up for my newsletter using the form down below.
Until next time.
