Contact Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a commodity feature. A "contact us" flow is low-complexity and high-visibility: it sits on the marketing site, feeds sales/support, and is expected to work forever. This package makes the build-vs-buy question explicit — buying it saves maybe a day of implementation, but the dependency itself becomes a roadmap liability (4 stars, 0 dependents, no visible maintenance cadence).
• Architecture decision: event-driven decoupling for inbound messages. The bundle's premise — a form submission dispatches an event that listeners consume — is the genuinely reusable idea. That seam lets you add a CRM push, a Slack notification, or a transactional email later without editing the form or controller. This is worth adopting as an internal pattern even if the package isn't adopted as a dependency.
• Feature scoping. It supports the narrow "lead intake + notify" use case well. It does not support the decisions most teams actually need to make around this feature: spam/bot mitigation, file attachments, GDPR/consent capture, routing rules by topic, or delivery guarantees (retry, failure handling). Those are separate decisions and separate work.
• Roadmap signal. A high opportunity score against near-zero adoption is a classic "real gap, immature solution" reading. If contact-form plumbing keeps recurring across projects, that argues for standardizing on a pattern (or a maintained alternative) internally rather than evaluating a bundle per project.
• Platform fit is a gating decision. Despite being described as a Laravel/PHP package, this is a Symfony bundle, and an old-lineage one. That reframes the decision entirely: for a Symfony 2/3 codebase it's a plausible drop-in; for Laravel or modern Symfony it is not a candidate at all.

When to Consider This Package

Consider it when:

• You maintain a legacy Symfony 2.x/3.x application that already depends on Frequence Web packages, and consistency with that stack has real value.
• You want a reference implementation of an event-based contact flow to read and re-implement (~a day of work), not to install.
• Your requirement is genuinely minimal: a form, a submit handler, and a dispatched event with no persistence, no anti-spam, no compliance needs.
• Your team already owns its dependency maintenance and can vendor/patch a small bundle if upstream goes quiet.

Look elsewhere when:

• The project is Laravel — there is no service provider, no publishable config in the Laravel idiom, and no reason to carry a Symfony bridge for a feature this small.
• You're on Symfony 5/6/7 or planning an upgrade; an unmaintained bundle becomes an upgrade blocker precisely when you can least afford one.
• You need anything beyond the happy path: spam protection, consent records, file uploads, CRM/ticketing integrations, delivery retries, audit trails, multi-recipient routing.
• You require supply-chain confidence — no security policy, no release cadence, no downstream users to catch regressions means your team is the de facto maintainer.
• The sensible alternatives already exist in the framework: Symfony's Form + EventDispatcher + Messenger, or Laravel's validation + events + queued jobs, cover the same ground with zero new dependencies.

How to Pitch It (Stakeholders)

To executives: This is a small, free library for adding a "contact us" form. It would save roughly a day of engineering, but it has almost no users and no active maintenance, which means we would own it forever — including security patches and framework upgrades. Recommendation: don't take the dependency; have engineering copy its event-based approach into our own code. Same benefit, no long-term risk. Budget one engineer-day, not a procurement cycle.

To engineering: The bundle's value is the pattern, not the code: submission → dispatched event → independent listeners for email, CRM sync, and alerting. That gives us a clean extension point for the integrations we know are coming, and it isolates the form from delivery concerns. It is, however, a Symfony bundle with negligible adoption, so pulling it into a Laravel or modern Symfony app buys us a framework-compatibility problem in exchange for very little. Proposal: implement the same event seam natively using the framework's own dispatcher and queue — a small, well-understood piece of code we control — and treat the bundle as prior art. If we later find this pattern repeating across three or more projects, that's our cue to standardize it as an internal package with real ownership rather than adopt an abandoned one.