Filament Survey Laravel Package

Product Decisions This Supports

• Build vs. buy for survey/feedback capability. This package is effectively a "buy-with-caveats" option: it gives you an admin-facing survey builder (surveys, sections, questions, entries, answers) inside Filament plus Excel export, for the cost of a Composer install instead of an estimated multi-sprint build. It directly informs whether NPS/CSAT, onboarding feedback, internal pulse surveys, or research intake become roadmap items this quarter or next.
• Scope framing for a feedback feature. Because v3.1.0 consolidated question/section management into relation managers on the survey resource (and entries + answers into one Entries resource), the plugin ships a coherent authoring workflow rather than raw CRUD. That lets you scope an MVP as "survey authoring + response collection + CSV export" without designing an admin UX from scratch.
• Localization as a product requirement, not a nice-to-have. The only reason to use this package instead of plain laravel-survey is the Tapp fork adding translatable and sortable fields. If multi-language surveys are on your international roadmap, this is the differentiator; if not, you are paying complexity for a feature you won't use.
• Analytics placement on the roadmap. The plugin is CRUD-first. Basic reporting is Filament tables and exports; real analytics (funnels, segmentation, trend lines, statistical significance on NPS) is a separate build. This is the decision point that most affects roadmap sequencing: adopt the plugin for collection, and plan analytics as a follow-on bet.
• Internal-tools leverage. For an existing Filament admin panel, this is a near-zero-marginal-cost capability for HR, customer success, or research teams — a credible "ship the internal tool now, productize later" path.
• A negative signal worth recording. The repository is archived and has zero dependents on the ecosystem side. That is a genuine input to the buy decision, not a footnote: it changes the TCO from "license + maintenance" to "vendored code we own."

When to Consider This Package

Consider it when all of the following hold:

• You are already running Filament 3.x or 4.x on Laravel 10+ / PHP 8.1+, and the admin panel is where operational users live. If Filament isn't in the stack, the plugin's entire value proposition (pre-built admin resources) evaporates and you should use laravel-survey or a form builder directly.
• Your need is structured, multi-question, multi-section surveys with persisted entries — not a one-off contact form. Ad-hoc forms are cheaper with Filament's native form builder.
• Multi-language surveys are a real requirement, which justifies the forked matt-daneshvar/laravel-survey on the dev-translatable branch rather than upstream.
• You accept owning a fork. The archived status means you are adopting a codebase, not a maintained dependency. Budget for a named owner, a vendored/private-mirror copy, and a plan for Filament 5.
• Excel/CSV export is acceptable as a deliverable for reporting in v1, and pulling in maatwebsite/excel is tolerable (or already present).

Look elsewhere when:

• You need a maintained, supported dependency. Archived + 32 stars + 0 dependents means no community safety net and no upstream fix path. For a revenue-critical or compliance-adjacent survey system (e.g., regulated feedback, contractual SLAs), this is disqualifying.
• Composer hygiene is a hard requirement. The install requires adding a VCS repository and a dev- branch constraint to composer.json. That means no semantic versioning guarantees on the survey engine, unstable CI installs, and a package that will trip dependency audits and security scanning. Teams with strict supply-chain policy should stop here.
• You are not on Filament, or are on Filament 2. Filament 2 is legacy; and non-Filament stacks should not adopt Filament just to get surveys.
• You need real-time or advanced analytics. This is a CRUD admin plugin, not a reporting engine; expect to build dashboards on top.
• Your existing schema already models surveys/responses. Migration and naming collisions against laravel-survey tables plus duplicate Filament resources create cleanup work that often exceeds the build cost.
• You need respondent-facing runtime UX. The package is authoring/admin-side. The public survey-taking experience, invitations, reminders, and partial-response handling are yours to build.

Recommended posture if you proceed: treat it as a seed/reference implementation — vendor the source, strip what you don't need, and keep the survey schema. Do not plan on upstream upgrades.

How to Pitch It (Stakeholders)

To executives (one paragraph): There is an open-source plugin that adds a complete survey tool — build surveys with sections and questions, collect responses, export to Excel — into the admin panel we already run, in days rather than the six-to-eight weeks a custom build would take. It supports multi-language surveys, which matters for our expansion plans. The trade-off is candid: the project has been archived by its author, so we would be taking ownership of roughly a few thousand lines of admin code rather than subscribing to a supported product. My recommendation is to use it as a time-boxed accelerator — a two-week spike to validate the survey feature with real users — on the explicit condition that we vendor the code and assign an owner. If the feature proves out, we own a working system at low cost; if it doesn't, we've spent two weeks, not two months.

To engineering (the honest version): This is a Filament plugin wrapping a forked matt-daneshvar/laravel-survey (Tapp's translatable branch, added via VCS repo in composer.json) to get translatable and sortable survey models. It requires Spatie Translatable, Spatie Eloquent Sortable, and maatwebsite/excel. Version branches map 1:1 to Filament majors (2.x/3.x/4.x). Three things to price in: (1) the dev-translatable constraint means no semver stability on the survey engine — we pin a commit hash and vendor it; (2) the repo is archived, so we are the maintainers and a Filament 5 upgrade is our problem; (3) the translatable layer adds joins per query — validate performance if a survey has many locales and high entry volume. Good news: it's self-contained, doesn't touch global state, and v3.1.0's relation-manager authoring flow means we can extend rather than rebuild the admin UX.

Decision requested: approve a two-week evaluation with a named engineering owner, a private mirror of both the plugin and the forked survey package, and a pre-agreed exit criterion (survey authored in two languages, 50 test entries collected, exported to CSV). Do not adopt without the owner and the mirror — that's the condition that turns an archived package from a liability into a cheap head start.