Forms To Wherever Laravel Package

Product Decisions This Supports

• Build vs. buy (partially: buy the seams). If you're on Statamic and need form submissions delivered to multiple downstream systems — CRM, ESP, helpdesk, data warehouse, internal webhook — this package is a candidate foundation rather than a finished feature. It encodes the "connector" abstraction once, so each new destination becomes a driver rather than a bespoke controller, queue job, and error path. The real buy/build question is whether to adopt the base abstraction and write thin drivers, or own the whole delivery layer.
• Roadmap scoping for form/martech integrations. Use it to estimate cost per destination: if a driver is genuinely incremental, integration backlog items (e.g., "send Contact form to HubSpot") shrink from days to hours, which changes how you sequence integration work versus other roadmap bets.
• Architecture direction for multi-destination submission. Product-visible behaviors — retry, failure notification, submission history, field mapping, per-form destination routing — are decided at the base layer. Choosing this package means committing to its opinions on those behaviors; deciding them yourself means committing to maintenance.
• Use cases it plausibly unlocks: routing Statamic form submissions to a CRM/ESP; fan-out to a webhook + Slack + warehouse; per-form destination configuration in the control panel; keeping delivery logic out of templates and controllers.
• Not a product decision it supports: anything outside Statamic. It is not a general Laravel form-delivery package, and should not appear on a roadmap that assumes framework-neutral form handling.

When to Consider This Package

Consider it when all of the following hold:

• You are already running (or firmly committed to) Statamic, and the Forms feature is in active use or on the near roadmap.
• You need more than one destination, or expect to. With a single destination, a small listener or webhook is cheaper than adopting an abstraction and its upgrade surface.
• You are willing to own the drivers. The base package is scaffolding; the delivery logic that matters to users still has to be written against it.
• You have confirmed compatibility with your Statamic major version and can verify the license, submission event hooks, and how failures/retries are surfaced — none of which is established by the current signals.
• Your team accepts a single-maintainer dependency for a non-critical path (form delivery), with a documented fallback (e.g., a plain queued listener) if the package goes stale.

Look elsewhere — or build in-house — when:

• You are not on Statamic. This is the decisive filter; the package's value is entirely Statamic-specific.
• You need guaranteed support, SLAs, or a security-review trail. Zero stars, zero dependents, and a minimal description do not constitute evidence of production use.
• You need one integration and a thin bespoke listener is cheaper to build and read than learning a third-party abstraction.
• Delivery is business-critical (e.g., paid lead capture) and you cannot absorb the risk of an unmaintained base layer sitting in the critical path.
• The abstraction turns out to be thin — if the base package is mostly a naming convention over Statamic's submission event, adopting it buys you little and costs you a dependency. Verify this early.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating an open-source add-on that standardizes how Statamic form submissions are sent to outside systems — CRMs, email platforms, webhooks. It is a foundation, not an off-the-shelf integration: it lets us add destinations cheaply instead of rebuilding delivery logic each time. The strategic upside is a lower cost per integration on our roadmap. The risk is maturity — it is early-stage, effectively unadopted, and maintained by one person — so it is suitable as an internal, non-critical-path accelerator under our review, not as a vendor commitment.

For engineering (summary): Proposed as the connector layer for Statamic form delivery. It provides the base abstraction (destination drivers over form submissions); we supply the drivers and the operational behavior we care about — retries, failure visibility, field mapping, per-form routing. Ask: is the abstraction deep enough to justify a dependency rather than a ~100-line queued listener? Confirm Statamic version support, license, maintenance activity, and whether it handles queueing and error surfacing or delegates both to us. Recommend a time-boxed spike: implement one real destination against it, alongside a bespoke listener, and compare lines of code, upgrade risk, and debuggability before any roadmap commitment.