Nova Mail Laravel Package

Product Decisions This Supports

• Build-vs-buy for admin email QA. If the roadmap has any line item like “let support preview and test-send transactional emails,” this package is the buy option. MIT license, small surface area, no vendor contract. The counterfactual is a hand-rolled Nova screen plus its maintenance — realistically a few days of engineering plus indefinite ownership. Adopt only if the capability is actually on the roadmap; otherwise it is shelfware with a maintenance tail.
• Unblocking the Nova 4 upgrade. Release 4.9.0 is the Nova 4-compatible release. If the team is committing to Nova 4, this flips from a standalone bet to a migration line item. Sequence it with the framework upgrade, not before it — and do not let it become the reason the upgrade slips or the excuse for it.
• Removing engineering from the email release loop. Today, verifying a transactional template change likely requires a developer and a deploy. A config-driven composer in the admin panel lets support or marketing compose, send, and eyeball a message without touching code. That is a throughput decision measured in engineer-hours per release, not a tooling preference.
• Controlling the blast radius deliberately. The package works against Laravel’s existing mail configuration, so existing transports and credentials apply. What gets exposed is a decision the PM owns: which mailers, which recipients, which environments. Keep it staging-first and gate the production send path behind a role, or you have shipped an open relay with a nice form.
• Validating demand for a broader email-ops roadmap. Compose → send → (eventually) template approval is a plausible wedge. Shipping two or three use cases cheaply tests whether anyone actually asks for template management before we fund it.
• Vendor-risk posture for internal admin tooling. 74 stars, zero dependents, no release since June 2022, effectively single-maintainer, no SLA. That profile is acceptable for auth-gated internal tooling with a named owner and a fork-and-own contingency. It is not acceptable anywhere in the customer-facing delivery path.
• A gate before any roadmap commitment: resolve the scope ambiguity. The description says “email composer in Nova.” The release notes also reference Model Event configuration with column/value conditions and a reworked DetailField.vue. Those are two different products with different owners and support burdens. Do not put a roadmap line item against this until someone confirms what it actually ships in staging.

When to Consider This Package

Strong fit when:

• You are on Laravel Nova and executing or planning the Nova 4 upgrade — 4.9.0 is the release that supports it.
• Support, marketing, or ops needs to send and sanity-check messages from the admin panel without running real customer flows or waiting on a deploy.
• You want an explicit allowlist of what can be sent, reviewed for PII, rather than a general-purpose mailer.
• You accept it as internal, auth-gated tooling: community-supported, forkable MIT code, no customer data leaving your stack.
• You can name an internal owner for upgrades, published-asset diffs, and any Vue/view customization.
• You are using it to test demand before funding internal template tooling.

Look elsewhere when:

• You are not on Nova. Filament, Livewire, or bespoke admin stacks get zero value — this is coupled to Nova’s action, field, and asset pipelines.
• You need delivery observability. Opens, bounces, clicks, suppression lists, and deliverability belong in the ESP dashboard.
• You need template management as a feature. Versioning, approval workflows, localization, A/B variants, segmentation — out of scope. This composes and sends; it does not manage.
• You need guaranteed maintenance. Single maintainer, no release since 2022. Any revenue- or compliance-critical dependency needs an owner identified up front or it needs a different package.
• You already have a working preview path. Mailpit, Mailhog, or a staging inbox may deliver most of the value without the version-tracking and asset-diff overhead.
• You are still on Nova 3. Ride the Nova 4 upgrade rather than merging this independently.

Adoption gates worth enforcing: Nova 4 confirmed; PHP/Laravel baselines verified against Composer constraints; exposed mailer list agreed and PII-reviewed; a named owner for published Vue/view customizations; a documented re-publish-and-diff procedure; and a staging-only pilot with a non-production mail transport.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) add-on that lets support and marketing send test messages from the admin panel we already run. No new vendor, no new system, no customer data leaving our stack. It removes a recurring dependency: checking an email change currently needs a developer and a deploy; with this, a non-engineer can confirm it before release. It also clears a compatibility blocker on the Nova 4 upgrade, since 4.9.0 is the Nova 4 release. The trade-off is maintenance profile — a small community package with a modest cadence and no release since 2022 — so we adopt it as internal tooling with a named owner and a fork-and-own contingency. Frame it as a low-cost, reversible bet, not a platform commitment. Success check: can a non-engineer catch a broken message without engineering help? If yes, it pays for itself. If not, we spent an afternoon.

To engineering: Nova Mail is a Nova tool plus a send-mail action that reuses our existing Laravel mail configuration. Integration is standard Nova lifecycle — Composer require, register in NovaServiceProvider, publish config, point the action at approved Mailables. Keep templates and recipients in code, not in the UI. Two operational risks to plan for. First, published-asset drift: if we customize the published DetailField.vue or modal views, upstream changes never reach us and the divergence stays invisible until someone diffs — make re-publish-and-diff part of the upgrade runbook and keep customizations minimal. Second, version-scheme churn: the maintainer has signalled aligning the package’s major/minor with Laravel/Nova, which changes what our Composer constraints mean — pin explicitly and bump deliberately alongside Nova upgrades. Also confirm the actual feature surface before we commit; the description and release notes describe different things. And re-validate any existing Model Event configurations, since a pre-4.9.0 bug left stale column/value conditions behind when event types were changed — upgrading alone does not repair existing rows.

Pilot recommendation: two or three messages, staging transport only, one week, written success criteria — a non-engineer spots a broken template unaided, and the send path gives clear failure feedback. Then decide.