Wind Laravel Package

Product Decisions This Supports

• Build vs. buy for contact intake. If the product already runs Laravel + Livewire + Filament, Wind is a credible shortcut for the "form on the marketing page → inbox in the admin panel" loop. A competent Laravel developer rebuilds the equivalent in one to two days, so treat this as a low-stakes either/or—not an architecture commitment. You are trading roughly a day of engineering time for one small upstream dependency.
• Roadmap prioritization. Contact capture is table stakes, not differentiation. Adopting the package lets the team spend the sprint on onboarding, billing, or the core workflow instead of form persistence and a review screen. Frame it as buying back capacity, not as adopting a platform.
• MVP scoping. Useful when the MVP needs a working lead path—demo requests, partnership inquiries, support contact, beta feedback—without standing up a CRM, helpdesk, or marketing-automation integration. It lets you ship "capture and review" now and defer "route, assign, automate" until volume justifies it.
• Admin surface consolidation. The Filament plugin registration forces an explicit decision about where submissions live. Keeping them inside the panel reduces tool sprawl and context-switching for ops; pushing them to a CRM or helpdesk is better long-term if submissions feed a sales or support process with owners and SLAs.
• Operational readiness gating. The package solves capture and display—not routing, assignment, SLA tracking, spam defense, or retention policy. The PM call is whether "capture and review" is sufficient for the next two quarters, or whether it quietly creates a backlog of unowned inbound leads nobody notices for weeks.
• Dependency posture. With ~35 stars, zero dependents, MIT license, and a single maintainer, this is explicitly a small, replaceable dependency. Decide to budget an escape hatch (fork or rebuild) rather than standardize on it across products. Recent releases are dependabot bumps and docs/translation chores—read that as maintenance-mode stewardship, not active product investment.
• Data ownership and compliance. Adoption means owning a table of PII (email, IP, message content). That triggers decisions the package does not make for you: retention windows, export format, deletion-request handling, and who has panel access. Assign an owner before go-live.
• Success measurement. Define the leading indicator up front—submissions per week and time-to-first-response—so a drop to zero is treated as an incident rather than a quiet Tuesday.

When to Consider This Package

Consider it when:

• The stack is already Laravel + Livewire + Filament, and the admin panel is the natural system of record for inbound messages. The install is then roughly 20 minutes; on any other stack it is a dead end.
• The requirement is genuinely one simple contact form with a basic review dashboard—not a form builder, not multi-form routing, not ticketing, not workflow automation.
• You are optimizing time-to-value on a low-to-moderate volume channel and would rather spend the sprint on product than on CRUD.
• The team can accept open-source, single-maintainer risk and is willing to pin the exact version, re-test on every Filament major, and fork if upstream goes quiet.
• Volume and stakes are low enough that a temporary workflow gap is recoverable—lost inquiries cost you a follow-up, not revenue-critical SLAs.
• You have, or can cheaply add, rate limiting, spam defense, and panel authorization around the form; the package does not provide these reliably.

Look elsewhere when:

• The stack is not Laravel/Livewire/Filament, or the panel is locked to a Filament major the package has not released against.
• Inbound messages are revenue-critical and need owners, SLAs, and routing—that is a CRM or helpdesk requirement, and a plugin inbox will become an unowned queue.
• You need multi-form support, conditional logic, file uploads, or integrations out of the box. You will end up building those anyway; start from a maintained form product or your own implementation.
• Compliance load is high (regulated data, strict retention, subject-access obligations) and you lack the appetite to build retention, export, and deletion on top of a dependency you do not control.
• Your organization requires vendor-backed support, SLAs, or a security review with a named maintainer. A 35-star package with a single maintainer and issue-tracker-only support will not clear procurement.
• It would become a shared dependency across multiple products. The blast radius of an abandoned package multiplied by N apps is not worth the day of saved work.

How to Pitch It (Stakeholders)

For executives (the 30-second version): We have a small, well-scoped gap—capturing inbound inquiries from the website and letting the team review them in the admin panel we already use. There is a free, MIT-licensed open-source package that does exactly that today, and the alternative is roughly one to two developer-days to build the same thing ourselves. I recommend adopting it for this one feature, wrapping it in a single swap point so it can be replaced in an afternoon, and pinning the version. The cost is one small dependency we do not plan to standardize on; the benefit is shipping the lead path this sprint instead of next.

For engineering (the ask): Verify the version matrix first—Filament major, Livewire, PHP constraint from the package's composer.json on the exact tag—because a mismatched Filament major is the difference between a 20-minute install and a dead end. Then: pin the version, publish and own the migration, configure rather than fork, keep the Blade tag behind one partial, hook downstream work (CRM sync, Slack, webhooks) on the submission model's created event with afterCommit(), and queue the notification so a slow SMTP server never turns a contact form into a 500. Add a policy to the Filament resource—submissions are PII and default Filament authorization is permissive—and rate-limit plus honeypot the public endpoint, because it is an unauthenticated write endpoint.

Risks we are accepting, stated plainly: This is maintenance-mode stewardship—~35 stars, zero dependents, one maintainer, a PR history dominated by dependabot and translation chores. The realistic failure mode is not an outage; it is silent lead loss—messages never persisted or never emailed, unnoticed for weeks. We mitigate with a test that asserts the row survives a notification failure, a daily submission-count alarm that fires on a drop to zero, and a written fork-or-rebuild decision on the shelf with a one-to-two-day estimate. We also own the PII obligations the package does not ship: retention window, export, deletion on request, and a defined audience for panel access.

What success looks like: The form is live, submissions land in the panel, the team has a named owner for the inbox, and we can answer "how many inquiries this week and how fast did we respond" without opening the database. If those hold and volume stays modest, we keep the dependency. If volume or routing needs grow, we swap the partial and move intake to a proper CRM—and that swap is a day, not a project.