Core Lib Laravel Package

Product Decisions This Supports

• Marketing automation as a product capability — segment-based campaigns, drip/nurture sequences, contact lifecycle scoring, form capture, and email engagement tracking. If the roadmap includes "lifecycle marketing," "onboarding sequences," or "lead nurturing," this is the underlying capability. Note that what you actually adopt is Mautic the service (API + webhooks); mautic/core-lib is its shared PHP foundation, not a library you install.
• Build vs. buy for the marketing stack — the real decision is "self-host an open-source marketing automation platform" versus "buy a hosted ESP (Mailchimp/SendGrid/HubSpot)." The package itself doesn't answer this; it frames the cost side, because you inherit hosting, patching, cron, and a second datastore.
• Feature scoping around segments and campaigns — segmentation and campaign membership are the integration primitives, not tags or ad-hoc lists. Product features like "put users in an onboarding track when they sign up" map to contact upsert → segment add → campaign trigger. Plan UX and instrumentation around that path.
• Data ownership and consent roadmap — contact records, engagement history, and consent status land in a second system. This forces early decisions on source of truth, GDPR/erasure spanning two datastores, and data-residency posture — decisions that are cheaper to make before launch than after.
• Transactional vs. marketing email split — the sequencing guidance (transactional email last) is a product decision about which channel rides on a new, less battle-tested system first.
• Roadmap timing against platform version — Mautic 4.4 targets PHP 7.4/8.0 with Symfony 4.4. If the infrastructure baseline is 8.2+, greenfielding on 4.4.x is a short-lived bet; the roadmap should plan the move to Mautic 5 up front rather than discovering it later.
• Make vs. integrate on the client side — no Laravel-native wrapper exists, so you own a MauticClient (Guzzle behind an interface, queued outbox). This is a small, bounded build decision, and worth accepting rather than blocking on a package that doesn't exist.

When to Consider This Package

Consider it when:

• The requirement is genuinely marketing automation — segmentation, campaigns, multi-step nurture, lifecycle email — not just "send some transactional email."
• You need self-hosting for cost, data-residency, or customization reasons, and are prepared to own a second PHP/Symfony application (PHP-FPM + MySQL/MariaDB + a cron suite for segment and campaign rebuilds).
• You have platform-engineering capacity to own uptime, patching/CVE response, and database backups — roughly one engineer at partial allocation — plus clear marketing-ops ownership of campaign configuration.
• Your integration surface is HTTP-shaped: REST API for writes, webhooks for inbound engagement events. Mautic's JSON API and form-encoded webhooks fit cleanly behind a queue.
• You can keep calls out of the request cycle — a queue-backed outbox and a circuit breaker mean a Mautic outage never takes down a signup form.
• Community support is acceptable, or you're willing to buy a commercial Mautic provider for anything customer-facing.

Look elsewhere when:

• You expected composer require mautic/core-lib. It is not a Laravel package — it will not boot inside your app, and its Symfony 4.4 DI container and ORM are disjoint from Laravel's. Treat it as a separately deployed service.
• A hosted ESP (Mailchimp/SendGrid/HubSpot) would satisfy the requirement with far less operational surface — usually true for straightforward newsletter/transactional needs.
• Your runtime baseline is PHP 8.2+ and you're not prepared to target Mautic 5 from the start.
• You need bidirectional real-time sync or sub-second consistency; Mautic is cron-driven and segment membership is not immediately queryable after an API call returns.
• No one can own the cron suite — omission is the single most common cause of "Mautic is broken" reports, and segments/campaigns fail silently without it.
• You need vendor-backed SLA support on the open-source distribution itself; 4.4 is community-supported.
• Someone proposes embedding Mautic inside the Laravel deployment. Strongly advise against.

How to Pitch It (Stakeholders)

For executives: This buys us marketing automation — segment-driven campaigns, onboarding sequences, form capture, and engagement tracking — as an open-source platform we host ourselves. The trade is clear: no license fee, but we take on a second application to run and patch, and it will eventually need an upgrade to Mautic 5 because 4.4 targets older PHP. Before committing, we should confirm a hosted ESP can't meet the requirement more cheaply, because our operations burden is the real cost here, not the software.

For engineering: mautic/core-lib is not a Composer dependency for our Laravel app — it is the shared foundation of a standalone Symfony 4.4 application we deploy separately and talk to over its REST API and webhooks. We own a thin MauticClient (bound to an interface, queue-backed outbox, retry/backoff, circuit breaker), a mautic_contact_id mapping on local models, and idempotent webhook receivers — Mautic posts form-encoded, retries deliveries, and won't create custom fields from API payloads. We also own the cron suite, OAuth/basic-auth credentials, and a second datastore holding contact PII, which means GDPR erasure must span both systems. Budget roughly one engineer at partial allocation plus marketing-ops ownership of configuration; the 4.4.1 upgrade itself is a low-risk patch-only no-op, but the habit of deferring Mautic patches is the real operational risk. Start with a spike: provision, authenticate, push and read back one contact, receive one webhook — that path exercises auth, field aliases, the contacts endpoint, and cron, which are the four things that break first.