Doorman Laravel Package

Product Decisions This Supports

• Gated access as a product surface, not a build project. Doorman turns "invite-only" into a configuration decision rather than a 1–3 day engineering task. That means the PM can commit to a private beta, design-partner program, or closed onboarding flow in a roadmap without opening an auth epic.
• Closed → open registration as a staged rollout. Because access can be granted per-code with use limits and expiry, you can sequence launch in cohorts (internal → design partners → waitlist tiers → GA) and widen the gate without a deploy or a new feature.
• Waitlist-to-activation funnel instrumentation. Invite codes are effectively unique, finite, trackable tokens. Issued vs. redeemed vs. expired becomes a defensible funnel metric — useful for judging whether demand is real or whether the bottleneck is the invite step itself.
• Build vs. buy, resolved toward buy. The capability is commodity: code generation, use limits, optional email binding, expiry, redemption middleware. At MIT license and zero recurring cost, the buy case is strong and the lock-in is shallow — the integration surface is a migration, a trait on the user model, and route middleware.
• A hedge against over-building auth. Teams often reach for a full RBAC or feature-flag platform to solve what is really "let only these people in for now." Recognizing that distinction early keeps scope out of the roadmap.
• Abuse containment by default. Rate-limited, expiring, single-purpose codes give you a natural throttle on uncontrolled signups during high-visibility moments (launch posts, press, Product Hunt) without standing up bot defense.

When to Consider This Package

Adopt when most of these hold:

• The application is Laravel with an Eloquent user model and standard registration.
• The need is genuinely access gating: invite codes, limited redemptions, expiry, email-restricted codes, protect-a-route middleware.
• You want it this sprint, with a small, readable, MIT-licensed dependency rather than a bespoke subsystem.
• Your team can accept a single-maintainer, community-scale package (~1k stars, low dependent count) and is willing to pin the version and wrap the integration lightly.
• Release cadence matters to you — a 2025 release is a reasonable signal of upkeep, but verify against your Laravel version.

Look elsewhere (or build) when:

• You need marketing-grade waitlist mechanics — referral codes, position-in-line, viral loops, drip email, landing-page capture. That's a SaaS product (LaunchList, Prefinery class) or a marketing-owned system, not a middleware package.
• You need authorization, roles, or feature flags. Doorman gates entry; it does not model permissions. Use Laravel Pennant / spatie/laravel-permission or a flag service.
• You need enterprise or SSO-driven provisioning — SCIM, domain capture, admin-approved onboarding. Different problem class.
• You operate outside Laravel, or your user model is non-standard enough that the trait/migration assumptions fight you.
• You require audit-grade access control (who granted what, when, with retention). Codes as a table are a start, but you'd be building the compliance layer yourself.
• Abuse resistance is the primary requirement at scale — treat Doorman as the gate, not the fence; pair it with rate limiting, CAPTCHA, and monitoring, or the security posture becomes someone else's ticket.

How to Pitch It (Stakeholders)

To executives: We can open a private, invite-only launch without adding an engineering project to the roadmap. This is a small, permissively licensed, actively maintained library — no vendor contract, no per-seat fee, no data leaving our infrastructure. It gives us a controllable dial on who gets in, and it generates the funnel data (invites issued vs. redeemed) that tells us whether launch demand is real. Primary risk is maintenance: single maintainer, modest community. Mitigation is a pinned version and a thin internal wrapper so we can swap it out in under a day if needed. Recommendation: adopt for gated rollout; revisit only if invite mechanics become a growth channel rather than an access control.

To engineering: One migration, one trait on the user model, one middleware alias. Invite codes support use limits, expiry, and optional email binding, and redemption emits events you can hook for analytics and onboarding email. It does not touch your auth stack or your authorization model — it's a gate in front of registration, not a replacement for it. Wrap it behind a small internal service so the package name appears in exactly one place, pin the version, and add rate limiting on the redemption endpoint. Budget: roughly half a day to integrate and test, versus two to three days to build equivalent behavior with tests and edge cases.