Walking Away from Centralised Auth
I tried a shared-auth pattern across Next.js apps. It mostly worked—until it didn’t. Here’s why I dropped it.
Posted by
KaiRelated reading
Reflecting on why the initial concept rarely matters as much as you think.
Embracing Minimalism in the MVP
How a bare-bones approach keeps your side project manageable and moving forward.
Avoiding Complexity That Doesn't Matter
Why offloading and skipping unneeded tasks can save your side business.
I’m setting up a portfolio of projects for my software engineering profile. Main site’s live on Next.js 14: oceanheart.ai. Looks good, solid base.
The idea: spin up a series of Next.js apps sharing one auth system. On sign-in, apps redirected to accounts.oceanheart.ai which handled login and issued magic links → tokens. Tokens refreshed via callbacks. Centralised auth, all apps consuming the same session.
It worked… until it didn’t. The dependency on Supabase sessions was brittle. Any tiny interference and the chain snapped. I ended up bolting on aggressive recovery mechanisms, nested/time-based API calls, all the duct tape. Debugging turned into a headache. Probably not good engineering.
So I made the hard call: put the tools down. I’d sunk ~16 hours of deep work chasing “almost there.” Yes, it rebooted some muscle memory and got me back into harder problems. But the slope was getting steeper, and I wasn’t confident the payoff justified the complexity. Maybe not the hill to build on.
Learning point: walk away sooner when the integration cost starts owning you. Centralised auth sounded elegant; in practice, it created tight coupling and failure modes I didn’t control.
More in the next entry. Signing out for now.