Laravel Waitlist Laravel Package

Product Decisions This Supports

• Build vs. buy for waitlists: v0.2.0 strengthens the case for treating this package as a self-hosted waitlist capability rather than buying a hosted waitlist/landing-page tool. Import, public count/position, reconfirmation and installable confirmation mail reduce the “we still need a vendor” gaps.
• Launch gating and social proof: ->publicCount() and ->publicPosition() let product/marketing show demand (“joined by 240 people”, “you’re #37”) without exposing subscriber emails. The privacy defaults matter for roadmap decisions: off by default, rounded down to ten, null below ten, and unavailable on lists without double opt-in.
• Retention and list hygiene: retention.reconfirm_after_days plus reconfirm_within_days turns the waitlist into a re-permissioning tool. This supports roadmap decisions around re-engagement, dormant-subscriber cleanup, and “lapsed” lifecycle states before launch.
• Migration from existing tools: waitlist:import / Waitlist::for($list)->import() keeps consent provenance (EntryImported with original consent time for confirmed imports), which is directly useful for legal/compliance review and for deciding whether to migrate from spreadsheet, Typeform, Mailchimp, or an older waitlist.
• Spam protection without vendor dependency: TimeTrapSpamProtector (hidden field + time trap) is a build-vs-buy decision point: it removes the need for reCAPTCHA/hCaptcha for basic form protection, at the cost of weaker protection than dedicated services.
• Multi-project/browser-facing waitlists: PublishableKeyResolver maps X-Waitlist-Key to a project, supporting product decisions around embeddable or multi-brand waitlist pages without exposing admin credentials.
• Operational maturity: --isolated command options, terminal prompts for missing arguments, waitlist:install --mail, and the new referral example support decisions to run the waitlist in production with scheduled jobs and safe concurrent deployments.
• Upgrade timing is a product decision: v0.2.0 is a minor version with breaking changes. If the team is on v0.1.x, roadmap planning must include Laravel 13 attribute migration, class renames, route method splits, enum case additions, and JS client upgrades before adopting new features.

When to Consider This Package

Consider it when:

• You are building on Laravel 13 and want a first-party-style waitlist package that uses attributes, form requests, and container bindings.
• You need double opt-in, consent provenance, and GDPR-friendly defaults without building subscription state machines from scratch.
• You want public waitlist counts and place-in-line but need privacy controls (rounded counts, opt-in-only visibility, no address-based lookup).
• You need to import existing subscribers while preserving consent records, or you need reconfirmation/lapse flows to clean dormant lists.
• You want self-hosted spam protection without integrating an external CAPTCHA service, and your threat model accepts a time-trap/bot-trap approach.
• You are running multiple waitlist projects and need a browser-safe publishable key resolver.
• You want artisan-driven operations (prune, rekey, wording, import/export/show) with isolation options for scheduled jobs.

Look elsewhere or defer when:

• You are not on Laravel 13 and cannot absorb the v0.2.0 breaking changes yet (renamed LinkGenerator classes, removed Waitlist::verifySpamUsing() / spamProtector(), ListPolicy::doubleOptIn() method, #[UseFactory] requirement for extended models, new enum cases, and GET/POST split mail routes).
• You need a full marketing automation/CRM platform with segmentation, A/B testing, drip campaigns, or deliverability tooling. This is a waitlist package, not an email marketing suite.
• You rely on pages using @taldres/laravel-waitlist 0.1.x and cannot upgrade to 0.2.0: earlier JS clients do not read count, position, challenge, or answer_by, and the release explicitly warns not to enable reconfirmation or TimeTrapSpamProtector on such pages.
• You are on MySQL/MariaDB with waitlist_wordings.project values longer than 100 characters. The new widen_waitlist_wordings_table migration shrinks the column to 100 and fails if longer names are stored; this must be cleaned up before upgrading.
• You need strong anti-bot guarantees. A time trap is useful, but it is not equivalent to a dedicated CAPTCHA/risk vendor.
• You require semver stability with no breaking changes in minor releases. v0.2.0 shows the package is still pre-1.0 and can change APIs; plan upgrade work accordingly.

How to Pitch It (Stakeholders)

To executives: This release turns the waitlist from a simple signup form into a launch-readiness tool. We can show social proof safely, import existing demand with consent records, re-confirm dormant subscribers before launch, and add basic bot protection without buying another SaaS product. That reduces vendor spend and time-to-market while keeping subscriber data in our own Laravel app.

To engineering: The package now aligns with Laravel 13 conventions and adds operational commands, import/export, retention flows, and a pluggable spam protector. The trade-off is a real upgrade task: renamed classes, removed spam binding methods, route method splits for confirm/unsubscribe links, new enum cases, factory attributes on extended models, and two new migrations. The JS client must be on 0.2.0 for count/position/challenge features, and MySQL/MariaDB project names must fit 100 characters before migration.

To marketing/growth: We can publish rounded waitlist counts and individual place-in-line, import existing subscribers, and run reconfirmation campaigns to keep the list healthy. Referral examples and wording/version fields support campaign iteration, but public count/position must stay off for lists without double opt-in and are off by default.

To legal/privacy: Consent provenance is improved through import tracking and explicit reconfirmation/lapse states. Public count and position features are constrained: counts are rounded down and hidden below ten, position is token-based rather than address-based, and both require list opt-in. These defaults support a privacy review rather than bypassing it.