Form Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (framework-gated): This is a Symfony bundle, not a Laravel package. It can only inform a "buy" decision for Symfony 8 / PHP 8.4+ estates. For a Laravel roadmap it is a hard no — the value is in avoiding boilerplate around Symfony's Form component, Twig rendering, and the akyos Core/CMS bundles, none of which transfer to Laravel. Any "buy" recommendation must be scoped to a Symfony service line, or the decision collapses to "build a Laravel-native form module."
• Feature scoping — contact/intake forms as a commodity: The bundle covers the standard 80% of lead-capture and support-intake needs: configurable fields without code, centralized submission storage, data export, Twig-ready rendering, and reCAPTCHA v3 spam mitigation. That is enough to ship a contact form, demo-request form, or feedback widget as a thin, low-differentiation feature rather than a roadmap item worth engineering weeks.
• Roadmap prioritization: Because it externalizes form CRUD, validation wiring, and submission persistence, it frees the team to spend the release on differentiators. Treat it as infrastructure, not product: it should not appear on the roadmap as a feature, only as a delivery accelerator with an explicit replacement path if requirements grow.
• Use cases it credibly serves: marketing/lead capture, customer support intake, MVP feedback collection, and a paid "Advanced Forms" tier in a SaaS product — the bundle owns the backend (fields, submissions, export) while product builds the differentiated UI and workflow layer on top.
• Use cases it does not serve: multi-step wizards, conditional branching with complex rules, file uploads, CRM/queue integrations, high-volume submission processing (no evidence of queueing, metrics, or batching), or anything resembling a form-builder platform. Those are separate build decisions.
• Vendor and maintenance risk as a decision input: 0 stars, 0 dependents, README-level maturity, and a hard dependency on two sibling akyos bundles (core-bundle, cms-bundle) means adopting this couples your CMS and your form layer to a single small vendor. That is a concentration risk the PM must price in, not a footnote — it argues for treating this as an internal fork candidate rather than a strategic dependency.
• Migration budgeting: The 8.0.3 release notes show the bundle was broken by Symfony 8's removal of Request::get(), patched only in the admin builder-editing path. That is a concrete signal of upgrade tax per Symfony major, and it belongs in the total-cost-of-ownership line, not the engineering backlog alone.

When to Consider This Package

Consider it when all of the following hold:

• The target application is Symfony ^8.0 on PHP >= 8.4, not Laravel. Confirm this first; if the estate is Laravel, stop here.
• You are already running akyos/core-bundle and akyos/cms-bundle. The form bundle is not standalone — adopting it into a clean Symfony app means adopting the CMS and core layers too, which is a much larger architectural commitment than "add a contact form."
• The requirement is a conventional contact/intake form: static-to-configurable fields, validation, email notification, submission list, CSV-style export, reCAPTCHA v3. No branching logic, no uploads, no async processing.
• Speed outweighs customization, and the team is willing to read source because documentation is README-only.
• You can accept single-vendor and zero-community risk, ideally with a plan to fork or wrap the bundle behind an internal interface so it can be swapped.
• You have budgeted for per-major-version maintenance (Symfony 8 required an admin-path bugfix; expect similar work at Symfony 9).

Look elsewhere when any of the following hold:

• Any Laravel requirement. There is no Laravel integration surface here; the Request bag migration, Twig rendering, and bundle registration model are Symfony-specific. A Laravel team should evaluate filament/forms, laravel-filament form builders, or a thin custom Livewire/Blade implementation instead.
• You need a form platform — drag-and-drop builder for end users, conditional logic, multi-step flows, file uploads, webhooks/CRM sync. The feature list does not reach there, and extending it means owning the extension.
• Volume or reliability is load-bearing. No evidence of queueing, retry, deduplication, or submission analytics; thousands of submissions per day is out of scope.
• Documentation quality is a hard procurement gate. Maturity is "readme"; there are no published guides, no tests/CI signals, and no community answers to fall back on.
• You need an auditable, well-maintained dependency for security review — 0 stars and 0 dependents is a difficult story to tell a security or compliance reviewer.
• A permissive, single-purpose alternative exists — Symfony's own Form component plus a mailer and a reCAPTCHA bundle covers most of this without the CMS coupling, at the cost of a small amount of boilerplate.

How to Pitch It (Stakeholders)

For executives (one paragraph): "We evaluated akyos/form-bundle as a shortcut for contact and intake forms. It works — it gives us configurable fields, stored submissions, export, and spam protection out of the box — but it is a Symfony-only component with a hard dependency on two sibling Akyos bundles, zero community adoption, and README-level documentation. My recommendation: approve it only for a Symfony service where we already run the Akyos CMS, where it saves roughly a sprint of form plumbing; do not adopt it for our Laravel work, and do not treat it as a strategic platform dependency. If we proceed, we wrap it behind an internal interface so it stays replaceable."

For engineering: "It's a Symfony bundle (PHP 8.4+, Symfony ^8.0) that replicates Contact Form 7: dynamic fields, submission storage, export, Twig rendering, reCAPTCHA v3 via karser/karser-recaptcha3-bundle. It is not usable from Laravel — the internals are Symfony Form, Twig, bundle registration, and Symfony HTTP Foundation parameter bags; the 8.0.3 patch specifically moved Request::get() calls to query/request bags for admin builder editing. Costs: it drags in akyos/core-bundle and akyos/cms-bundle, so it is an ecosystem commitment, not a drop-in; reCAPTCHA arrives through a dev-stability third-party package, which is a supply-chain review item; and there is no redirect handling, so every submit handler must redirect explicitly to avoid resubmission. Recommendation: adopt behind a FormService interface, pin to a known-good patch (^8.0.3 minimum on Symfony 8), plan for a fork if the vendor stalls, and keep the option of Symfony's native Form component as the exit ramp."

For design/UX: "The bundle owns submission handling, validation messages, spam protection, and email delivery — it does not dictate the frontend. We control the Twig markup and can style freely, and translation overrides mean multi-language forms don't require new infrastructure. The constraint to design around: no multi-step flows, conditional branching, or file uploads without custom work. Please mock the form UI independently in Figma and confirm we're designing within a single-step form before the backend integrates."