Contact Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for support intake: It clarifies the minimum viable "contact us" capability — storefront form, validation, message persistence, email notification to a configurable recipient, and an admin-facing list of inquiries. Use it as a feature checklist, not as a dependency.
• Build vs. buy vs. borrow: This lands firmly in "borrow the design, build the code." The domain is commodity support plumbing (two entities, one form, one email, one admin CRUD view), so a Laravel team can reproduce the entire behavior in idiomatic Laravel faster than it can absorb Sylius/Symfony conventions.
• Roadmap framing: Contact intake is not a differentiator by itself. The product value sits in what happens after submission — routing by topic, ownership and SLAs, spam/abuse controls, retention of PII, and CRM/helpdesk handoff. Roadmap investment should go there, not into evaluating an archived bundle.
• Platform decision input: If the question is "should our Laravel product use this?", the answer is no, and that answer is decisive rather than marginal — archived repo, 5 stars, 0 dependents, no upstream maintenance. This is a clean "no" that frees the team from further diligence.
• Risk posture: Adoption would mean fork-and-own: security patching, PHP/Symfony compatibility work, and test coverage for a non-core workflow. That cost is disproportionate to the feature's value.
• Use cases it meaningfully informs: pre-sales inquiries, storefront contact forms, simple customer-support message capture, back-office message triage. It does not support decisions about ticketing, omnichannel support, SLA automation, CRM sync, or any differentiated support product.

When to Consider This Package

Consider it only when all of the following are true:

• The product is already a Sylius/Symfony storefront, not a Laravel application.
• The need is a small, isolated contact form or inquiry inbox — not a support platform.
• The team has confirmed the current Sylius version does not already ship this functionality in core (a real duplicate-install risk).
• Someone is explicitly willing to own the fork: pinned dependencies, added tests, upgrade and security work.
• License and PHP/Symfony/Doctrine compatibility have been verified against the current stack.

Look elsewhere when:

• The application is Laravel-first. There is no service provider, facade, config file, or Eloquent model to register; integration would mean reimplementation, not adoption.
• You require maintained dependencies, security updates, or vendor support.
• You need ticket assignment, SLAs, automation, analytics, omnichannel routing, or CRM integration.
• You are selecting a long-lived production dependency. Archived status plus zero dependents is a strong avoidance signal.
• You need modern abuse protection. The bundle offers little beyond Symfony defaults — no meaningful rate limiting or CSRF/spam story for a public form.

Default recommendation: Build a thin Laravel-native intake flow — a ContactRequest model, a form request with validation plus honeypot/throttling, a queued mailable triggered by an event listener, and an admin resource with a status enum. Optionally use the bundle's source as a reference for domain shape.

How to Pitch It (Stakeholders)

Executive summary: We should not adopt this package for a Laravel product. It is an archived Symfony/Sylius bundle with negligible adoption (5 stars, 0 dependents) and no maintenance path. The business risk — unpatched security exposure and silent breakage during framework upgrades — clearly outweighs the limited value of a standard contact form. Building the equivalent capability natively is a small, well-understood piece of work.

Engineering summary: Architecturally this is a Sylius bundle: Doctrine resources, Symfony forms and routing, Sylius resource configuration for customization, and SyliusGrid for the admin inbox. It will not drop into Laravel's container, Eloquent, Blade, or queue conventions. The capability itself is roughly two models, one form with validation, one queued mailable, and one admin CRUD screen with a status transition — all reproducible with native Laravel primitives in less time than it takes to learn the override layers and then own a fork.

Product recommendation: Treat contact and support intake as a workflow and integration problem, not a package-selection problem. Prioritize routing by topic, abuse and spam controls, admin visibility with clear ownership, PII retention policy, and helpdesk/CRM handoff. Keep an archived dependency off the roadmap entirely; if we are on Sylius and need this immediately, fork it behind a bounded interface with a named owner and a plan to replace it with an in-house module.