I had it scheduled for a day. One day. "Set up auth." That's the line I wrote in my plan, with the smug confidence of a man who has clearly forgotten every previous time he's set up auth.
The plan was clean on paper. Supabase handles authentication — email and password, plus Google login for hosts who want calendar sync later. Hosts sign up, hosts log in, done. Supabase does the heavy lifting, I just wire it up. Easy day. I even told Durga I'd be free for dinner.
I was not free for dinner.
The first wall hit almost immediately, and it wasn't technical — it was a product realization that quietly broke my entire plan. Hosts logging in? Fine. But Book A Sloth's whole soul is that a guest can book and pay without making an account. That's the promise. Nobody wants to create a login just to book a 30-minute session with their tutor. The moment you force a signup on a guest, you lose half of them. I've watched it happen. The signup wall is where bookings go to die.
So here's the contradiction I walked straight into: I need authentication — I need to know the guest is real, that the email is theirs, that someone can't book as a stranger — but I cannot make them create an account. I need to verify a person without registering a person.
That's not what a normal login system is built for. Supabase Auth is brilliant at "create accounts and log them in." It is not designed for "verify a human who will never have an account." I sat there for a while just feeling the shape of the problem, because I'd architected the whole thing assuming auth was one box, and now there were clearly two: hosts who have accounts, and guests who never will.
The answer, I realized, is OTP. A one-time code. Guest enters their email, we send them a code, they type it back, and now we know that email is really theirs — no account, no password, no friction. I started sketching a separate little system for it, an otp_codes table, living alongside Supabase Auth rather than inside it. Two
doors into the same house: a real login for hosts, a lightweight OTP gate for guests. (I'll go deep on building that tomorrow, because it has its own pile of landmines.)
But that realization cost me the whole afternoon, and then the evening went to something dumber and more maddening: a redirect loop. Late night number one of this project. I'd log in, the server would think I wasn't logged in, bounce me back to login, where the client thought I was logged in, which bounced me forward, which bounced me back. An infinite hallway of doors. The root of it was that classic Next.js + Supabase headache — the server and the browser disagreeing about whether you're authenticated, because the session lives in one place and the server's looking in another.
I'm not going to pretend I solved it elegantly. I solved it at 1 a.m., tired, by carefully getting the server and client to read the same source of truth about who's logged in. The fix was small. Finding it was not.
But before I crawled into bed, the small win that makes these nights worth it: a host signed up, logged in, landed on their dashboard, and stayed logged in on refresh. The hallway of doors was gone. Login worked.
One door done. The harder, weirder one — OTP for guests who'll never have an account — is tomorrow.
Auth was supposed to be the easy part. Auth is never the easy part.