Your Demo Doesn't Need Auth
When building a demo application, I believe you can often skip authentication.
Picture this: a coding school student team demoing a project. Smart and creative folks with lots to offer. Yet they spend half of their limited building and demoing time on auth. Here’s a sample script from the demo:
“So we click ’login’ and now we’re on the login page, which we know because the header says ‘Log in.’ Then, we can either log in, sign in, or reset our password. We’re going to log in with a username and password I set up before the demo. I just fill in the username ‘demo-user’, password ‘password’, click ‘submit’, and now… wait for it… I’m on my homepage. See my username in the navbar? That only shows up when I’m logged in.”
I’m exaggerating here, a little.
Let me concede that auth is important. Most software depends on it for roles, privacy, and a sense of ownership and belonging. In production software, you almost always are going to need it. It’s the first or second feature of most web applications.
If that’s true, why omit it from the demo? I believe that auth:
- Should always be feature-driven
- Is yak-shaving you might be able to delay solving
- Is boring in a presentation
- Wastes time and creativity
Let me address each of these.
First, auth should be feature-driven. The Lean Startup encourages us to rapidly iterate. You don’t have time to build most things because you’re prioritizing speed. If a feature demands it– security, privacy, showing account information– add auth. When it doesn’t, don’t.
Second, auth is yak-shaving. I’ve implemented auth many times, regrettably rolling my own, using libraries, and using SAAS tools. Each time, I survey the changing auth marketplace, choose a tool, sign up for an account, and wade through sales-oriented docs. It’s a schlep. I’d like to postpone it for as long as I can.
Third, auth is boring in a presentation. Unless your project is auth-as-a-service or includes unusually sensitive information, nobody cares about auth. When I was first learning to program, implementing auth was satisfying. The rest of the world doesn’t care. It’s invisible unless it’s unusual or broken. The point of a demo is to show progress and generate excitement, and auth doesn’t do either of these.
Finally, auth torpedos creativity. If you have time to build two features, should one of them be password reset? Save that time to show how you might make somebody’s life better.
Skip auth, hard-code “demo-user” into the navbar, have fun, and build something great.