The latest articles on DEV Community by Ron (teRON) Bullock (@teronbullock). https://dev.to/teronbullock https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F878842%2F7035189c-9601-4eac-b3a6-c7867dc5b31b.jpg https://dev.to/teronbullock en Ron (teRON) Bullock Thu, 26 Mar 2026 23:34:31 +0000 https://dev.to/teronbullock/why-i-deleted-my-custom-crew-logic-mid-build-2mp5 https://dev.to/teronbullock/why-i-deleted-my-custom-crew-logic-mid-build-2mp5 <p>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.</p> <p>I looked closer at my auth layer and realized my provider <code>better-auth</code>'s native <code>organization</code> plugin already handled multi-tenant access control. This was the exact problem I was solving from scratch.</p> <h2> The Mid-Build Pivot </h2> <p>At that point I had two choices:</p> <ul> <li>Keep the custom implementation and own it long-term</li> <li>Adopt better-auth's native organization plugin and retire my abstraction</li> </ul> <p>The trade-off was obvious. My custom "Crew" layer duplicated what <code>better-auth</code> was already handling; the member schema, tenant context, permission propagation.</p> <p>Keeping it meant owning edge cases, permission logic, and future schema drift. The Pivot meant letting the library handle what it was built for.</p> <h2> Why the Native Approach Won </h2> <p>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. </p> <p>The pivot wins were:</p> <ul> <li>Eliminating a redundant abstraction instead of maintaining parallel systems</li> <li>Staying aligned with better-auth's data model instead of fighting it</li> <li>Reducing long-term maintenance across auth, sessions, and permissions in one move</li> </ul> <h2> What Improved </h2> <p><strong>Simplified State Management</strong><br> Removing the custom Crew layer cut unnecessary renders and tightened component isolation across authorized views. Less state to thread through, cleaner boundaries.</p> <p><strong>Stronger Authorization Boundaries</strong><br> 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. </p> <p>That gave me cleaner, more reliable schema enforcement for:</p> <ul> <li>Member invitations</li> <li>Role assignments</li> <li>Member asset edits (passwords, profile info)</li> </ul> <h2> Tradeoffs </h2> <p>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.</p> <h2> My Takeaway </h2> <p>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.</p> architecture javascript buildinpublic react