Filament Survey Laravel Package

Technical Evaluation

Architecture fit

The package is a thin Filament UI layer (resources, relation managers, widgets) over matt-daneshvar/laravel-survey, which owns the domain model — surveys, sections, questions, entries, answers. That separation is clean in principle: the plugin adds admin CRUD, the underlying package owns schema and persistence. For a TPM this means the actual architectural commitment is not this plugin but the survey data model, and the plugin is replaceable while the schema is not.

Fit is narrow but real: Filament 3.x/4.x admin panels that need structured survey authoring (sections, ordered questions, translatable prompts) plus response review and Excel export. It is not a survey delivery engine — there is no public-facing respondent flow, no conditional logic, no scoring, no analytics beyond what Filament tables give you. Any roadmap item involving "participants take the survey" or "we compute NPS/CSAT" is out of scope and must be built separately.

Critical caveat: the repository is archived. That reframes the entire evaluation. The plugin is a frozen artifact, not a living dependency. Everything below assumes you treat it as a code sample you adopt, not a package you depend on.

Integration feasibility

Installation is documented and short, but the dependency graph is the hard part:

• The plugin requires a forked laravel-survey (tappnetwork/laravel-survey, branch translatable) added as a VCS repository. This is not a tagged release — it is a mutable branch reference. Composer will happily resolve it once and then silently drift, or fail to resolve at all if the branch is renamed or deleted.
• It requires the Spatie Translatable Filament plugin to be registered alongside it, which means your panel inherits translatable-form behaviour globally, not just for surveys.
• It pulls maatwebsite/excel transitively for export — a heavy dependency to inherit for one feature.
• It uses spatie/eloquent-sortable for ordering, which imposes a sort_order column and model trait behaviour on your question/section tables.

Feasibility is high if you are already on Filament 3.2+/4.x and already comfortable with a VCS-pinned fork. It drops sharply if you are on Filament 2.x (branch-only support, effectively EOL) or if your app has any existing survey/forms schema you would have to reconcile.

Technical risk

Key questions

1. Is the business need survey authoring for internal admins, or survey delivery to end users? Only the former is covered.
2. Can we fork this into our own namespace and pin the forked laravel-survey to a commit SHA rather than a branch? If not, this is not production-grade.
3. Are we on Filament 3.2+/4.x today, and is there a Filament 5 upgrade on the roadmap within 12 months? If yes to the latter, budget for a rewrite.
4. Do we need multilingual surveys? If no, most of the value of the fork (and most of its risk) disappears, and a simpler in-house schema is preferable.
5. Who owns the survey tables — us or the package? Once published and migrated, that schema is ours forever, including the vendor's design decisions.
6. Is there an existing forms/survey capability in the product that this would duplicate?

Integration Approach

Stack fit

Good fit: Laravel 10–12, PHP 8.1+, Filament 3.2+ or 4.x admin panel, internal-tool or SaaS back-office where surveys are an admin-managed artefact. Low fit: anything without Filament (you would be adopting an entire admin framework to get a survey builder), anything needing respondent-facing flows, and anything with an existing survey or questionnaire domain model.

The pragmatic read: this is a reference implementation worth ~1–2 weeks of build time, not a strategic platform dependency.

Migration path

Recommended path is adopt-and-own, not require:

1. Fork both repositories into your own org. Tag the forked laravel-survey at a fixed commit; replace the dev-translatable VCS reference with your own pinned fork.
2. Install the forked survey package and publish/verify its migrations against a scratch database. Audit every column and index before it touches a shared environment.
3. Install the plugin at ^3.0 (Filament 3) or the 4.x branch (Filament 4), then immediately vendor it if you intend to patch it.
4. Register FilamentSurveyPlugin and SpatieLaravelTranslatablePlugin in the target panel provider — verify the translatable plugin does not alter behaviour on unrelated resources in that panel.
5. Publish and review config (filament-survey-config), especially the resources array, to control whether Section/Question resources appear as standalone nav items or only as relation managers.
6. Decide on export upfront. If Excel export is not a launch requirement, strip the dependency rather than carrying it.
7. Backfill, don't migrate. If prior survey data exists, write an explicit ETL into the new schema rather than attempting in-place migration.

Compatibility

Filament versions are branch-pinned, not release-pinned — 2.x, 3.x, 4.x live on separate branches. That is an unusual and fragile distribution model: composer require resolves the default branch, so a mis-specified constraint can silently land you on the wrong major. Pin exact constraints. The translatable fork diverges from upstream matt-daneshvar/laravel-survey (PR #39 was never merged upstream), so upstream fixes will not reach you and upstream releases will conflict. Treat the survey package as permanently forked.

Sequencing

• Phase 1 — Spike (1 week). Stand up in a throwaway branch against your real Filament version. Prove CRUD on surveys → sections → questions → entries, and confirm the translatable plugin does not regress other admin resources. Go/no-go gate here.
• Phase 2 — Fork and pin (2–3 days). Own the code. Replace branch references with SHAs. Add CI (the upstream has Pint only).
• Phase 3 — Schema hardening. Indexes on entry/answer lookups, foreign-key behaviour on survey deletion, and a decision on soft deletes for responses.
• Phase 4 — Feature completion. Whatever the business actually needs that the plugin does not give: respondent flow, analytics, notifications, permissions.
• Phase 5 — Optional dependency removal. If export is unused, drop maatwebsite/excel and the export actions.

Do not sequence this as "install then extend"; sequence it as "evaluate, then take ownership."

Operational Impact

Maintenance

This is the dominant cost. An archived repository with zero dependents means you are the maintainer from day one. Concretely: no Filament 5 compatibility will arrive, no PHP 8.4/8.5 fixes will arrive, no security advisories will be issued, and no dependency-conflict resolutions will be published. Budget a recurring slice of engineering capacity — realistically a few days per Filament major upgrade, plus ad-hoc work when maatwebsite/excel or spatie/eloquent-sortable bumps a major. The forked laravel-survey compounds this: two forks to track, one of which is a branch-only divergence from a package whose author has not merged the required PR.

The honest TPM position: approve this only with a named internal owner and an explicit "we forked it" note in the architecture record.

Support

No vendor support, no issue triage, no SLA. The TappNetwork org appears to have produced this as an internal tool released publicly — the release cadence (v3.0.0 through v4.0.0 largely driven by one contributor) reflects maintenance-mode stewardship, and archiving confirms it. Internal support burden falls on whoever integrates it. Ramp-up for a new engineer is moderate: Filament resource conventions are well documented, but the plugin's own patterns (relation-manager-centric authoring introduced in v3.1.0) are undocumented beyond the README and must be read from source.

Scaling

The plugin itself is stateless CRUD; scaling is really a question about the survey schema. Answers are stored per-question rows, so a 40-question survey at 10k responses is ~400k answer rows — fine for MySQL with proper indexing, problematic for the Filament entries table without pagination tuning and eager loading. Translatable fields multiply question/section rows by locale count, which inflates authoring queries but not response volume. Export is the real scaling cliff: maatwebsite/excel loads large result sets into memory, so a 10k-response export will need chunked/queued handling that the plugin does not provide. Plan for exports to run as background jobs, not synchronous admin actions.

Failure modes

• Composer resolution failure. The dev-translatable VCS branch disappears or is force-pushed → builds break irreproducibly. Mitigation: fork and pin to SHA.
• Filament upgrade breakage. A Filament minor bump changes a resource API → admin survey pages 500. Mitigation: pin Filament minor versions; test the panel in CI.
• Translatable plugin cross-contamination. Registering SpatieLaravelTranslatablePlugin globally changes form behaviour on unrelated resources. Mitigation: verify on a dedicated panel first.
• Migration drift. Published survey migrations become immutable history; any later fork changes require new migrations. Mitigation: audit schema before first production migrate.
• Export OOM. Large export times out or exhausts memory in the admin request cycle. Mitigation: queue exports, cap row counts.
• Silent data model coupling. Custom code written against unmodified laravel-survey models diverges from the fork's translatable/sortable additions. Mitigation: document the fork's deltas.

Ramp-up

Low-to-moderate for a Filament-fluent engineer: a day to read the plugin source and the laravel-survey fork, two to three days to a working local environment. Higher for anyone unfamiliar with Filament — the resource/relation-manager mental model is the learning curve, not the survey domain. Given the archive status, the more important ramp-up is institutional: whoever inherits this must know it is a fork-of-a-fork, and that knowledge needs to live somewhere other than a Slack thread.

Recommendation for the portfolio: score reflects code quality and documentation, not strategic viability. The opportunity: 1.88 is the signal that matters — there is no ecosystem, no upstream, no forward path. Use it as a time-saving reference for a 1–2 week build, adopt it only under a fork with a named owner, and treat any dependency on it in a customer-facing or long-lived product as a deliberate technical-debt acceptance rather than a routine package install.