Mailchimp Laravel Package

Product Decisions This Supports

• Build vs. buy for lead capture. "Newsletter signup" is a recurring, low-differentiation ask from marketing. This addon replaces a custom Mailchimp API v3 wrapper, auth handling, and merge-field mapping — roughly 1–3 engineer-days plus ongoing maintenance — with a composer require and two environment variables. The buy case is strong precisely because the integration is commodity.
• Feature scope for existing forms. It lets us add subscriber capture to contact, gated-content, webinar, waitlist, and download forms without a new form backend or a client-side JS tag. That is a feature-flag-level decision, not a platform decision — we can ship it on one form, measure conversion, then roll out.
• Roadmap sequencing / deferring the ESP decision. Adopting this buys us time: we can satisfy "we need email capture" now without committing to a marketing-automation platform. It also draws a useful line — one-way push to a list is not lifecycle marketing. If the roadmap includes journeys, segmentation, or behavioral triggers, this package does not discharge that requirement, and we should say so explicitly rather than let stakeholders assume it does.
• Sync direction and data ownership. The v6.2.5 change caps audience pulls at 500 records per call, which tells us the maintainers position this as a subscribe tool, not a bulk sync engine. That is a real product decision: do we invest in incremental pull-and-reconcile work (queued jobs, high-water marks, idempotent upserts) to bring audience data back into our own database, or do we keep Mailchimp as system-of-record for the list and treat our app as write-only? Default to write-only unless there's a concrete segmentation or reporting need.
• Audience and consent model. "Support for list selection" means someone must decide: one audience or several, who owns membership routing, and whether double opt-in is required. Consent capture, privacy-policy copy, and the GDPR/retention posture are product decisions this package cannot make for us — and the one it's easiest to get wrong.
• PII boundary. Every form wired to this addon sends names and emails to a third party. That is a data-processing decision worth a documented review, not a line item in a sprint.
• Platform/ecosystem bet. Adopting a Statamic-native addon reinforces Statamic as the CMS standard and avoids per-site bespoke code across our portfolio. It also creates a dependency on a small addon ecosystem — a supply-chain consideration to weigh once, then revisit at renewal.

When to Consider This Package

Adopt when:

• The site is already on Statamic. This is the single strongest criterion; the value proposition collapses outside that ecosystem.
• The requirement is one-way: front-end form submission → subscriber on a Mailchimp list. No reverse sync, no local mirror of the audience.
• The list is small to mid-size (hundreds to low thousands) and the form set is bounded — a handful of forms with a small number of merge fields.
• You want configuration-as-environment (API key, audience ID in .env) so credentials survive config:cache and don't live in version control.
• You have at least one engineer comfortable reading PHP who can wrap the addon behind an internal service, add Http::fake() fixture tests, and pin the version.
• MIT licensing and negligible cost fit the budget envelope, and reversibility matters — this is a two-day decision to undo.

Look elsewhere when:

• The application is Laravel-only, not Statamic — use the official Mailchimp Marketing PHP client or a general Laravel wrapper directly. You'd be paying the Statamic dependency tax for nothing.
• You need bidirectional or incremental sync at scale. The 500-record pull ceiling in v6.2.5 means bulk export/reconciliation is out of scope; budget real engineering for cursors, queued jobs, and idempotent upserts, or pick a tool built for it.
• You need lifecycle marketing: journeys, automations, tags/segments managed in-app, e-commerce events, or transactional email (that's Mailchimp Transactional/Mandrill, a separate product entirely).
• You need compliance tooling built in — consent audit trails, retention policies, DSAR workflows. This addon collects and forwards; it does not govern.
• You need an ESP abstraction layer (multi-provider, easy switch to Klaviyo/HubSpot/Braze). Better to build the thin internal interface first and treat this addon as one adapter.
• Vendor-risk tolerance is low. 18 stars and a small maintainer pool is a genuine bus-factor concern for a business-critical capture path. If marketing's lead flow cannot tolerate a stalled integration, either accept the risk with an abstraction and an exit plan, or pay for a supported integration.
• You need inbound webhooks or real-time Mailchimp events feeding the app — not in scope here.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed Statamic addon that turns the forms we already have into Mailchimp subscriber capture, configured with an API key and an audience ID. It removes a custom-integration task from the backlog for roughly the cost of a configuration change, requires no new vendor contract, and is trivially reversible. It gets us email capture this sprint without forcing a marketing-automation platform decision we're not ready to make. The trade-offs are honest and small: it's a lightweight community addon with limited adoption, so we'll pin the version, wrap it behind a thin internal service, and keep an exit path. It does not replace lifecycle marketing or audience sync — if those appear on the roadmap, they're a separate conversation.

For engineering (one paragraph): A thin wrapper around the Mailchimp API for Statamic forms — install via Composer, credentials and audience ID in .env, merge fields mapped per form. v6.2.5 is a patch release (a 500-record audience-pull cap plus CI bumps), so no migration work; run config:clear and queue:restart after upgrading, and pin the version in composer.json. Treat any pull as paged, not as a dataset: stream page-by-page into storage from a queued job, log fetched / total so truncation is visible, and prove the loop terminates on an exactly-full final page with Http::fake() fixtures. Persist raw payloads before normalizing and key writes on the provider's member ID for idempotency. Keep our integration behind an internal service class so we can rebind the interface or swap providers without touching form code, and so patch upgrades stay low-risk.

Risks to state up front: single-maintainer dependency, low adoption signal, silent truncation on pulls, and — the one that's genuinely ours — PII and consent handling, which the package does not solve for us.