Contact Form Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the contact-form feature. This package supports a build-in-house decision for a Laravel product, not an adoption decision. A validated contact form with email delivery, anti-spam, consent capture, rate limiting, and basic social share links is small and well-understood — roughly 1–3 dev days in Laravel using first-party validation, Mail, queues, CSRF, and middleware.
• Framework-fit gate. Despite being labeled a Laravel/PHP package in intake, idci/contact-form-bundle is a Symfony2 bundle, not a Laravel package. It ships Symfony bundle wiring (AppKernel, service config, Twig, Symfony Form types), so there is no viable integration seam in Laravel. For a Laravel roadmap this is a hard stop, not a spike.
• Maintenance-risk triage. 1 GitHub star, 0 dependents, Symfony2 end-of-life since 2018, and likely Swiftmailer/Twig transitive dependencies are all signals of an abandoned artifact. The PM decision is to log it in the dependency-risk register as evaluated and rejected, not to vendor or fork it.
• Roadmap scoping. The contact-form feature itself should be scoped independently: field set, validation rules, recipient routing, spam posture, consent/retention requirements, accessibility, and whether submissions are stored or only emailed. Those requirements can be extracted without taking on the package.
• Social sharing as a separable concern. The “social sharing” half of the package should not be coupled to the contact-form decision. Replace it with signed share URLs or a maintained front-end share component; the package’s sharing scope adds third-party JS/tracking surface for degraded endpoints.
• Opportunity-score read-through. The composite score of ~0.71 reflects packaging metadata, not fitness for a Laravel stack. The opportunity score of 0.38 is the more honest PM signal: this is not a strategic lever, at best a reference implementation to skim for form-field and validation ideas.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining an un-upgradeable legacy Symfony 2.x application and need a drop-in contact form with basic social sharing.
• The feature is low-stakes and internal-facing — no payment, regulated data, or PII-heavy workflows.
• You can vendor/fork and patch the code yourself, assuming no upstream fixes, security monitoring, or issue triage.
• Your spam, accessibility, and consent requirements are minimal and you are willing to bolt them on.

Look elsewhere — or build natively — if any of these are true:

• You are on Laravel. There is no compatible integration path; do not spend a spike on it.
• You are on Symfony 5/6/7. Use Symfony’s current Form component and a maintained contact-form bundle instead.
• You need GDPR/consent capture, audit logging, rate limiting, or robust anti-spam (honeypot, CAPTCHA, Altcha). The package predates modern expectations and you will re-implement these anyway.
• You need file uploads, multi-recipient routing, CRM/webhook delivery, or localization. Build where you control the mail transport and validation rules.
• Supply-chain or security review matters. An unmaintained, zero-dependent package with no recent commits is a poor security posture, especially for a form that ingests names, emails, and free-text messages.

How to Pitch It (Stakeholders)

Bottom line: do not adopt for Laravel. idci/contact-form-bundle is a Symfony2-era bundle with 1 GitHub star, zero dependents, and no active maintenance. Symfony2 has been end-of-life since 2018, so “reuse” here actually means inheriting an unpatched codebase and owning it permanently.

Recommend instead: build the contact form natively in Laravel (~1–3 dev days) using FormRequest validation, a Mailable over the Mail facade, queue-backed delivery, CSRF, rate limiting, and a honeypot or maintained CAPTCHA package. Add simple share links as a separate front-end concern. This gives us consent capture, anti-spam, and accessibility done to our standard, with no framework-mismatch risk.

Why this is a cheap decision: the feature is small and non-differentiating; the only real risk is accidentally coupling it to an abandoned dependency. Skipping this package removes a long-term maintenance liability at effectively zero delivery cost.

Ask: approve the in-house build and log this package as evaluated-and-rejected so we do not re-litigate it next quarter. If a stakeholder wants a reference for field design, we can skim the bundle’s templates once — but we ship our own code. Do not vendor it “just in case.”