Filament Newsletter Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side newsletter tooling: this package is a Filament panel integration layer over jeffersongoncalves/laravel-newsletter. It lets you ship subscriber list management, campaign CRUD, and send actions inside an existing Filament admin rather than building those screens or adopting a separate ESP dashboard. The decision it informs: do we build internal newsletter admin UI, adopt a hosted ESP, or wrap an existing Laravel package with Filament resources?
• Localization / market expansion roadmap: release 1.1.0 adds 17 locales (ar, az, de, es, fa, fr, hi, it, ja, nl, pl, pt, ru, tr, uk, uz, zh_CN). That is a concrete enabler for launching in EU, MENA, CIS, and APAC markets without maintaining your own translation files. Product call: can we treat admin-side i18n as solved and spend effort on customer-facing copy instead?
• Internal operator experience investment: non-English-speaking marketing or support staff can operate the newsletter admin in their own language. This supports decisions about who owns newsletter operations (central marketing vs. regional teams) without a training tax.
• Timeline/scope negotiation: because the UI layer is largely pre-built, the remaining scope is subscriber data model, consent/GDPR flows, and ESP/provider selection (the underlying package's driver). Useful for sizing a "newsletter in the admin panel" epic as small.
• Trial/pilot go-ahead: low integration cost means you can pilot in a staging admin and validate workflows (import subscribers, build a campaign, preview, send) before committing to a provider contract.

When to Consider This Package

Adopt when:

• You already run Filament (v3/v4-era) and want newsletter management as panel resources rather than a bolt-on app.
• Your newsletter needs are modest and campaign-oriented — subscriber lists, campaigns, send — not advanced automation, journeys, segmentation, A/B testing, or deliverability analytics.
• You need admin-side multilingual UI now; 17 locales is a meaningful head start.
• You are comfortable that deliverability, bounce handling, unsubscribe/compliance, and sending infrastructure are the underlying package's responsibility, not this one's.

Look elsewhere (or plan to build) when:

• You need enterprise ESP features: drip sequences, behavioral triggers, revenue attribution, inbox placement tooling.
• You require a vendored/audited dependency posture. Note 1.1.0 bumps jeffersongoncalves/laravel-newsletter from ^1.0 to ^2.0 — a major-version jump in the layer that actually sends mail. Treat the changelog as insufficient evidence of behavior compatibility; verify provider drivers, config keys, and any published migrations against 2.x before upgrading. That work belongs in the upgrade ticket, not the release note.
• The project is single-maintainer critical path — the release is almost entirely one author plus Dependabot and a docs/funding commit set. Bus factor and long-term maintenance are real risks for anything customer-facing and compliance-adjacent.
• You need customer-facing localization; these translations cover the admin UI only.

Migration guidance: pin to 1.0.0 if you cannot absorb the laravel-newsletter 2.x review this sprint; the i18n additions are additive and low-risk on their own, but they arrive coupled to the dependency bump.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost integration that puts newsletter management directly inside our existing admin panel, so we get subscriber and campaign tooling without buying another SaaS seat or building screens from scratch. The new release adds 17 languages to the admin interface, which means regional teams can run campaigns in their own language from day one and we can enter EU, MENA, and APAC markets without a translation project. The trade-off is that this is a thin UI layer over a single-maintainer open-source sending library — so we should treat it as a fast, cheap pilot, keep our provider choice flexible, and budget a short technical review of the upgraded sending dependency before we rely on it for customer-facing email.

For engineering: Filament plugin wrapping jeffersongoncalves/laravel-newsletter; 1.1.0 is additive on the surface (17 locale files, CI/workflow and funding chores) but ships with a major bump of the underlying newsletter package to ^2.0. Review that diff for config and driver changes before upgrading, confirm queued sending and unsubscribe routes still behave, and keep the plugin behind our own thin service boundary so the ESP is swappable.