Nova Unlayer Field Laravel Package

Product Decisions This Supports

• Build vs. buy for content authoring. This is the cheapest possible answer to "should we build our own drag-and-drop email/landing-page builder?" A thin MIT-licensed bridge between two products you likely already pay for — Laravel Nova as the admin surface and Unlayer as the visual editor — reframes the question as "a one-to-two-day integration" versus "four to eight weeks building a worse editor plus indefinite maintenance." The PM decision is whether visual authoring is core differentiator (build, own it) or commodity table stakes (buy, integrate, move on). For most teams it is the latter.
• Whether to make campaign content self-serve. If marketing, lifecycle, or growth teams file engineering tickets for every template tweak, this field converts an existing Nova resource into a self-serve authoring surface. That is a cycle-time and support-cost decision first and a technical decision second — quantify it in tickets avoided and lead time removed, not in story points.
• Scope and consolidation of the admin panel. It supports keeping operational tooling inside Nova — users, orders, content, campaigns — rather than fragmenting into Nova plus a marketing CMS plus a separate page builder. One permission model, one login, one system of record. Every additional admin surface carries a real cost in access reviews and onboarding.
• Transactional vs. marketing content roadmap. Good fit for campaign emails and simple landing pages where speed and visual polish matter. Poor fit for a versioned, localized, governed content platform. Adopting it forces the team to say out loud which of those it is actually building this quarter.
• Vendor consolidation and procurement. Nova and Unlayer already carry invoices; this converts two existing line items into shipped capability. That is a materially easier approval conversation than onboarding a third SaaS with its own contract, security review, and integration work.
• Delivery sequencing and reversibility. Small surface, exportable output (HTML plus design JSON), additive migration, no destructive schema change. It can ship inside an existing sprint to prove value before a larger CMS investment is approved — and be unwound cheaply if it disappoints. Treat it as an option, not a commitment.
• Where content governance will live. Adopting this makes explicit that approvals, versioning, localization, A/B testing, audit trails, and send-side rendering are not solved here. Surfacing that gap early — and assigning owners — is itself a valuable decision, and better made now than discovered at launch.
• Which use cases to greenlight first. The honest first use case is internal, low-blast-radius content: lifecycle campaigns, product announcement emails, simple promo landing pages. It is not the right vehicle for legally reviewed, multi-locale, or high-stakes transactional mail until sanitization and rendering fidelity are proven.

When to Consider This Package

Consider it when all of the following hold:

• You already run Laravel Nova in production and it is genuinely the system of record for the teams who will author content.
• You have, or will buy, an Unlayer plan, and you accept its per-seat/export pricing and the implication of loading third-party JavaScript inside an authenticated admin.
• Content in scope is campaign emails and simple landing pages — visual, brand-driven, edited by non-engineers — not structured, versioned, or multi-locale content.
• Your team is PHP/Laravel-centric with limited frontend bandwidth; a hand-rolled drag-and-drop editor is out of reach this quarter on any realistic estimate.
• You can absorb the maintenance risk of a small package: ~34 stars, zero dependents, single-organization maintainership, and a release date (2026-07-14) that should be verified against tags rather than trusted as a health signal. Budget for vendoring or forking the small surface yourself.

Look elsewhere when:

• You are not on Nova, or plan to migrate off it (Filament, Livewire/Inertia admin, headless CMS). The integration is Nova-shaped and does not port.
• You need approval workflows, content versioning, localization, A/B testing, or audit trails. Unlayer composes content; it does not govern it. You will build that layer regardless, so price it into this option.
• Vendor lock-in or data residency is a hard constraint. The editor is hosted SaaS, and templates live in a design JSON blob you must export and back up.
• Your email needs are developer-authored and highly dynamic (Blade/Markdown templates, heavy conditional logic, per-user content). A visual builder adds ceremony rather than leverage.
• You are cost-sensitive at the margin — this requires two paid products to justify one feature, and Unlayer tiers gate watermark removal, export, and collaboration.
• Security review flags third-party script execution inside an authenticated admin surface. Validate CSP, API key scoping, and where design JSON is stored before committing.
• Authoring already lives in a mature ESP editor (Braze, Customer.io, Mailchimp) that the content team is happy with. Then this is duplicate tooling and a second place to look for a template.

How to Pitch It (Stakeholders)

To executives: Marketing and lifecycle teams are blocked on engineering for every email and landing-page change, and each request competes directly with product work. This package puts a professional drag-and-drop editor inside the admin panel we already operate, using a design tool we largely already license. The realistic alternative is four to eight weeks of engineering to build a worse version of the same editor, plus indefinite maintenance. Here, integration cost is a day or two and the recurring cost is two SaaS subscriptions we already carry. The trade-offs are honest: dependency on two vendors and a small, low-adoption open-source connector. So we treat it as a fast, reversible bet — content is exportable as HTML and design JSON, and the integration is small enough to fork or replace if it disappoints. Approving this buys optionality and cycle time, not a platform commitment.

To engineering: This is a thin MIT-licensed Nova field that embeds the Unlayer SDK and persists its design JSON alongside exported HTML on your model. It is not a framework or a platform — expect to own the surrounding concerns: validation and sanitization of exported HTML, storage and versioning of the design blob, permissions, preview and test-send, tracking, unsubscribe, and backups. Audit before adopting: single maintainer, zero dependents, and a future-dated release — so pin the version, read the small source, verify Nova/PHP/Vue compatibility in a spike, and be prepared to fork. Watch the CSP implications of loading Unlayer's script in an authenticated admin, keep the Unlayer key server-side and scoped, and persist a schema version with each record so renders stay reproducible. If the package's assumptions do not fit our model layer, reimplementing the same embed directly is a realistic fallback — which is also the best evidence that lock-in here is low and the downside is bounded.