Statamic Mailerlite Laravel Package

Product Decisions This Supports

• Audience segmentation strategy. Prior to 0.0.5, a form or submission could target a single MailerLite group, which forced segmentation decisions to happen after the fact (or not at all). Multi-group selection moves segmentation into the capture moment: one signup can land in a product-interest group, a lifecycle-stage group, and a newsletter group simultaneously. That unlocks personalized campaigns, conditional automations, and per-segment reporting without a second data pipeline.
• Form and funnel consolidation. Instead of maintaining near-duplicate forms per segment, a single form can fan out to multiple groups. This is a direct reduction in content-ops overhead and in the number of places a tracking/consent change must be applied.
• Roadmap scoping for lifecycle messaging. If the roadmap includes onboarding sequences, lead scoring, or trial-to-paid nurture, multi-group tagging is the enabling primitive. It is worth sequencing this adoption before committing to a lifecycle program.
• Build vs. buy. The capability is small and well-bounded (API client + fieldtype + submission hook). Building in-house is a few days of work plus indefinite maintenance against MailerLite API changes; adopting the package is a maintenance transfer, not a build.
• Use-case fit: marketing-site newsletter capture, gated content downloads, webinar/webinar-replay registrations, product-launch waitlists, and interest-based preference centers — anything where one identity legitimately belongs to more than one audience.

When to Consider This Package

Adopt when:

• The stack is Statamic (this is a Statamic addon, not a general Laravel package — it assumes Statamic's form/submission and fieldtype plumbing). If the project is plain Laravel, look elsewhere; a thin MailerLite SDK wrapper is the right shape.
• MailerLite is already, or is about to become, the system of record for email audiences — this is a sync layer, not a replacement for one.
• You need multi-group assignment (0.0.5+), which is the main functional reason to prefer this over simpler single-group integrations.
• You want configuration over custom code: editors assign groups in the control panel rather than engineers wiring API calls.

Look elsewhere or wait when:

• Version maturity is a concern. This is a 0.0.x release. Pre-1.0 semver means no stability guarantee, and the 0.0.4 → 0.0.5 change modified group-selection behavior (singular → multiple). Any consumer storing a single group ID, or any template assuming a scalar, should be treated as a potential migration. Audit existing usages and pin the version in composer.json rather than floating.
• Bidirectional sync is required. This package is oriented around pushing subscriptions from Statamic to MailerLite. If you need unsubscribe propagation, engagement data back into the CMS, or field-level sync, that is out of scope — plan for a middle layer or a different tool.
• Compliance surface is large. Multi-group subscription raises consent questions: does subscribing to three groups constitute three consents, or one? Confirm the package's opt-in semantics and audit trail match your GDPR/CAN-SPAM posture before enabling it broadly.
• You need enterprise ESP features (transactional at scale, advanced deliverability tooling). MailerLite itself, not this package, is the limiting factor.

How to Pitch It (Stakeholders)

To executives: A small, low-cost integration update that lets a single signup flow sort contacts into multiple email audiences at once. The business value is sharper segmentation — fewer irrelevant sends, better-targeted campaigns, and less manual list maintenance. It removes a known constraint on marketing's ability to run interest-based nurture. Cost is a dependency bump, not a project.

To engineering: Release 0.0.5 extends group selection from single to multiple in the Statamic MailerLite addon. Low implementation effort — upgrade the package — but two real caveats. First, it is pre-1.0: pin the version and expect no semver protection. Second, the change is behaviorally breaking for anyone relying on a scalar group value, so grep templates, blueprints, and stored content for single-group assumptions and add a fallback for the array shape. No changes to Laravel core, no new services, no migration path required beyond that audit.