DEV Community

Ron (teRON) Bullock
Ron (teRON) Bullock

Posted on

Why I Deleted My Custom "Crew" Logic Mid-Build

I was deep into building a custom "Crew" management system for my Next.js SaaS, a job and invoice tracker for small businesses. Everything was all set. My hooks were in place state was wired up and my UI components were all working.

I looked closer at my auth layer and realized my provider better-auth's native organization plugin already handled multi-tenant access control. This was the exact problem I was solving from scratch.

The Mid-Build Pivot

At that point I had two choices:

  • Keep the custom implementation and own it long-term
  • Adopt better-auth's native organization plugin and retire my abstraction

The trade-off was obvious. My custom "Crew" layer duplicated what better-auth was already handling; the member schema, tenant context, permission propagation.

Keeping it meant owning edge cases, permission logic, and future schema drift. The Pivot meant letting the library handle what it was built for.

Why the Native Approach Won

I wasn’t evaluating a dozen alternatives. I was already on better-auth for auth and session management. The organization plugin just extended that to tenant context.

The pivot wins were:

  • Eliminating a redundant abstraction instead of maintaining parallel systems
  • Staying aligned with better-auth's data model instead of fighting it
  • Reducing long-term maintenance across auth, sessions, and permissions in one move

What Improved

Simplified State Management
Removing the custom Crew layer cut unnecessary renders and tightened component isolation across authorized views. Less state to thread through, cleaner boundaries.

Stronger Authorization Boundaries
I already had Zod validation at the API boundary in my custom solution; carrying it forward here just meant it now worked in concert with better-auth's permission model rather than around it.

That gave me cleaner, more reliable schema enforcement for:

  • Member invitations
  • Role assignments
  • Member asset edits (passwords, profile info)

Tradeoffs

The main tradeoff was reduced flexibility for highly custom role logic. But in exchange, I gained consistency, less code to maintain, and tighter integration with the rest of the auth system.

My Takeaway

It’s easy to get attached to a solution after you’ve put hours into it. But knowing when to pivot is key. Sometimes the better solution is the code you never have to write.

Top comments (0)