Unlayer Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for email/landing-page composition. If your product roadmap includes letting internal teams or end customers design emails, popups, or simple landing pages, this package is the "buy/integrate" path: it wires Unlayer's hosted drag-and-drop editor into a Filament admin panel instead of your team building a block-based editor from scratch (a multi-quarter effort on its own).
• Admin-tooling roadmap and time-to-value. For Laravel teams already standardized on Filament, this collapses an integration that would otherwise be bespoke glue code (Unlayer embed JS, auth/export handling, saving design JSON and rendered HTML) into a plugin install. That's a schedule lever on internal-tool roadmaps, not typically a customer-facing differentiator.
• Feature bets it unlocks: marketing-ops self-service (campaign and template creation without engineering), template versioning workflows, and — depending on how you wire Unlayer's export — HTML export into your existing sending pipeline (Mailgun, SES, Postmark, etc.).
• Make-vs-integrate on the editor itself. This package assumes Unlayer as the editor vendor. Choosing it is effectively a vendor commitment to Unlayer's licensing/pricing model; the PM decision is really "Unlayer + Filament" as a bundle, and the package is the cheap part of that decision.
• Not a decision it supports: anything about deliverability, sending infrastructure, or customer-facing email rendering at scale. This is an authoring-surface integration, not an ESP.

Assessment caveat: v1.0.0's release notes contain only an auto-generated changelog link — no feature list, migration notes, or compatibility matrix. The above is scoped from the package's identity (unlayer-filament, a community Filament plugin), not from documented release content. Treat specifics as unverified until engineering does a short spike.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel + Filament and want the editor inside the existing admin panel rather than a separate tool.
• Unlayer is already chosen or acceptable commercially (seat/usage pricing, data-processing terms, self-hosted vs. cloud constraints).
• The workflow is internal-team authoring (marketing ops, content ops) — not untrusted end-user authoring, which raises multi-tenancy, asset isolation, and abuse concerns the package likely does not solve for you.
• You need design portability: storing Unlayer's design JSON so templates are re-editable, plus rendered HTML for sending.
• You can absorb community-package risk: community-sdks namespace, v1.0.0, no prior release history. That means no track record for security response, Filament major-version tracking, or Unlayer API changes.

Look elsewhere or build your own when:

• You need a maintained, SLA-backed integration — prefer a first-party/vendor-supported plugin or budget for in-house ownership of this one.
• Your Filament version is newer or older than the package's supported range; a 1.0.0 community plugin is unlikely to span Filament majors. Verify compatibility before committing.
• You need deep product integration — conditional content per user segment, localization pipelines, approval workflows, or template governance. A thin wrapper won't cover these; you'll be extending it, at which point you own it.
• You are not on Filament (plain Laravel/Livewire, Nova, or a JS frontend). The Filament binding is the package's entire value; without it you're better off with Unlayer's JS SDK directly.
• Licensing or data residency rules out Unlayer's hosted editor.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small, free, community-built adapter that lets our existing admin panel host a professional drag-and-drop email/page designer instead of us building one. It's a schedule and cost saver on internal tooling — low spend, low strategic risk, but also low strategic value, and it comes with vendor and maintenance dependencies we should own consciously. It is not a customer-facing feature on its own.

To engineering: It's a Filament plugin wrapping Unlayer's embed. Our work isn't the install — it's the seams: how designs are persisted, how HTML export feeds our sending provider, asset storage, and permissions. Two asks before we commit: (1) a one-day spike confirming Filament version compatibility and that the package's persistence model fits ours, and (2) an explicit owner, because community-sdks at v1.0.0 with a changelog-only release means we are effectively the maintainers if it breaks or stalls.

To finance/procurement: The package is free; Unlayer is not. The real cost line is Unlayer licensing plus the engineering time to own a community dependency. Frame the comparison as "Unlayer + this plugin + ~X days integration" versus "build an editor in-house (~months)" versus "buy a different editor with a supported Laravel path."

Recommendation: Worth a time-boxed spike if email/page authoring is on the near-term roadmap and we're already on Filament. Do not adopt as a platform dependency without verifying compatibility, confirming the Unlayer commercial terms, and naming an internal owner. Revisit once the package has a release history and documented Filament version support.