Mailables Viewer Laravel Package

Product Decisions This Supports

Email review as a self-serve workflow, not an engineering request. Today, verifying a transactional email — receipt, password reset, onboarding sequence, billing alert, account notification — usually means filing a ticket, waiting for an engineer to trigger a send, and reviewing a screenshot of uncertain provenance. This addon puts rendered HTML and plain-text previews of every discovered mailable behind the Statamic Control Panel you already authenticate against. That converts an hours-long round trip into a URL, and eliminates the wrong-template-reviewed failure mode that comes from ad-hoc sends.

Deep links as review artifacts (v1.1.0). The ?mailable= parameter makes each preview a stable, shareable URL that can be attached to a Jira ticket, Slack thread, PR description, or release checklist. This is the difference between a tool that gets demoed once and one that earns a place in the definition-of-done for any change touching email copy. Roadmap implication: if you adopt, standardize on the deep-link convention immediately — the list view alone will not survive contact with a busy team.

Release gating and launch readiness. "Verify all transactional emails post-deploy" becomes a checklist of links rather than a scavenger hunt. That gives design, QA, and support a single authoritative artifact to sign off against across onboarding, billing, and notification surfaces — and makes email copy review a repeatable step rather than a favor.

Build vs. buy: adopt, but cheaply. Rebuilding this is roughly a route, a controller that resolves mailable classes, and a Blade wrapper — perhaps a day of engineering. The durable value is not the code, it is the ergonomics: control-panel-native access behind existing auth, zero-config discovery so the tool keeps working as your mailable inventory grows, and now deep links. Adopt it in require-dev, and keep the trivial fallback in your back pocket. Do not let it become load-bearing.

Explicit non-goals to set expectations early. This is not a deliverability tool, not a cross-client rendering fidelity check (Outlook/Gmail quirks are out of scope), and not an automated regression suite. Frame it internally as review tooling, not testing tooling. Mailable assertions and a catcher like Mailpit or Mailtrap remain the answer for those problems.

Ecosystem signal, not a platform bet. Eleven stars, zero dependents, a single-feature release, and one external contributor on the headline capability. That is fine for convenience tooling on a Statamic-based property with a near-zero exit cost — it is not a strategic dependency and should not be sold as one.

When to Consider This Package

Adopt when:

• You are on Statamic and ship transactional or notification email via Laravel mailables, and non-engineers (PM, design, marketing, support) regularly need to see that copy.
• You want previews behind the authentication you already have, rather than standing up a separate preview app or leaving a permanent staging route exposed.
• Zero-config discovery matters — mailables in the conventional location render without per-class wiring, so the tool stays useful as the set of mailables grows.
• Review handoffs are a recurring friction point, and deep links would slot directly into existing tickets, docs, and release checklists.
• You can scope it to local/staging with a named owner and a documented URL convention.

Look elsewhere or proceed with caution when:

• You are not on Statamic. This is an addon, not a drop-in for plain Laravel. A small bespoke route is the better investment.
• You need assertions, not eyeballs. Regression coverage belongs in mailable tests or a mail-capture tool. Do not position this as a substitute; the mismatch will surface at exactly the wrong moment.
• Production exposure is unresolved. Previews render real content, which may include recipient data or internal-only copy. Install as require-dev, gate to non-production, and verify the route is behind CP auth by testing it from outside the panel — not by reading config.
• The ?mailable= implementation accepts raw FQCNs. Resolving a class from a query string is an object-instantiation and information-disclosure surface if unvalidated. Before adoption, engineering should confirm allowlist or namespace-prefix validation, graceful failure on invalid input, and an environment guard. Treat this as a blocking question, not an assumption.
• Mailables require constructor dependencies. Mailables needing models or DTOs are the most likely rendering failure. Test this case explicitly and document it as a known limitation, or a non-engineer will file it as a bug.
• You depend on a large, actively maintained vendor surface. Small contributor base and thin release cadence mean: pin to ^1.1, add a review line at each Statamic major upgrade, and keep the fork-or-replace exit ready.
• Fidelity to real inboxes is the actual requirement. Different problem, different tool.

How to Pitch It (Stakeholders)

For executives: This is low-cost, low-risk developer tooling that removes a recurring bottleneck in email review. Verifying a transactional email — a receipt, a password reset, an onboarding note — typically requires an engineer to trigger a send and paste a screenshot into a ticket. That round trip costs hours of elapsed time per change and creates real error exposure when the wrong template gets reviewed. This package gives stakeholders a live, authenticated preview inside the control panel they already use, and v1.1.0 makes each preview individually linkable so review threads point at one authoritative artifact instead of a screenshot of uncertain provenance. It is a Statamic addon with no infrastructure footprint, no migrations, no changes to the send path, scoped to non-production. Adoption is reversible in an afternoon; the exit cost is a controller and a view. The ask is small: one owner, one environment guard, one documented URL convention, and a short runbook note for the known limitations.

For engineering: A dev-only dependency (require-dev, ^1.1) that surfaces mailables through a Control Panel route with no changes to your send path, no queue interaction, and no production behavior. No migrations, no schema, no config publication required; upgrading from 1.0.x is purely additive and existing viewer URLs keep working. Four things to validate before rollout: (1) whether ?mailable= accepts a raw FQCN or validates against an allowlist or namespace prefix, and that invalid values fail gracefully rather than throwing a framework exception; (2) that the route is auth-gated and unreachable outside local/staging — verified by probing it, not by inspection; (3) that mailables with constructor dependencies either resolve or are documented as unsupported; (4) that Statamic/Laravel/PHP constraint ranges are satisfied per property. Note two known limitations in the runbook: class renames silently break saved deep links with no compile-time protection, and non-engineers will read a hard error as "broken." If the addon goes stale, the replacement is a route plus a controller — copy the deep-link pattern into that fallback regardless, so the workflow investment outlives the dependency.