Voyager Forms Laravel Package

Product Decisions This Supports

• Build vs. buy for form capture. If Voyager is already the admin layer of a Laravel app, this package collapses a "custom form CRUD" backlog item into an afternoon of configuration — admin-defined fields, stored submissions, no deploy per change. That makes it a real third option alongside (a) building forms in-house and (b) paying for Typeform/Jotform/Formstack.
• Roadmap sequencing. Forms are almost always supporting infrastructure, not a differentiator. Adopting something thin and free lets you defer a proper form builder and spend the quarter on core product — an explicit "good enough for now" bet you should record as a bet, not a silent default.
• Data ownership and architecture. Submissions land in your own database via Laravel migrations/models rather than a SaaS tenant. That materially simplifies GDPR/data-residency review, export needs, and joining form data to core records.
• Credible use cases it covers. Internal intake/request forms, contact-us, lead capture, simple surveys, config-driven fields that ops teams change without engineering.
• Scope-cost signal. The package is deliberately thin. Assume you will own notifications, validation edge cases, conditional logic, file uploads, spam protection, and exports. That's a roadmap line item, not a footnote.
• What it does not decide. It is not evidence for "we can ship customer-facing or regulated forms cheaply." Different risk profile, different tool.

When to Consider This Package

Consider it when:

• Voyager is already running in production (realistically Voyager 1.x, Laravel 5.5–7.x era).
• The need is internal or low-stakes — a broken form is an annoyance, not an outage or a compliance event.
• There's no budget for SaaS forms or a custom build, and there is in-house PHP/Laravel capacity.
• You are willing to fork it into your repo and own it, pinned to your PHP framework versions.
• You're in a time-boxed MVP or discovery phase where speed beats longevity.

Look elsewhere when:

• Greenfield, or on Laravel 9/10/11 — archived since April 2020, no compatibility work, no security patches, no dependency updates.
• Forms are public-facing and touch PII, payments, health or financial data, or carry WCAG/audit obligations.
• You need support, an SLA, a vendor relationship, or CVE response.
• Requirements include multi-step flows, conditional logic, calculations, or third-party integrations — a maintained builder will be cheaper than extending this.
• Nobody on the team can read PHP/Laravel well enough to triage issues at 2am.

How to Pitch It (Stakeholders)

For executives. pvtl/voyager-forms is a free, MIT-licensed add-on for the Voyager admin panel we already run in our Laravel app. It lets non-technical staff create and edit forms and read submissions without engineering time, and it keeps that data in our own database rather than a vendor's — which shortens privacy review and removes a subscription line. The honest caveat: the project is archived, last released April 2020, with ~59 GitHub stars and no maintainer. There will be no security fixes or framework upgrades; if we adopt it, we are buying a head start, not a dependency. Recommendation: use it as a starter kit behind the admin for low-risk internal forms, budget a few days of engineering to fork, audit, and pin it, and keep it away from customer-facing or regulated data. If forms become a core product surface, we should switch to a maintained builder or a SaaS vendor and plan that migration deliberately.

For engineering. It's a small Voyager BREAD-style module — config-driven fields plus a submissions table. Treat it as vendored code: copy into the repo, update dependencies, add tests around the submission path, and document the fork. A one-to-two-day spike will tell us whether the schema and extension points are good enough before we commit.