Nova Mailman Laravel Package

Product Decisions This Supports

• Local/staging email inspection without a third-party dependency — replaces or defers adoption of external tools (Mailtrap, Mailhog, HELO) for teams that want mail review inside the app itself. Decision: build vs. buy for the "see what we actually sent" workflow.
• Mail retention and data-lifecycle policy — 1.2.0 adds a destroy route and in-tool removal of mails. This is the first release that supports a real retention story (purge sent mails, clear test data, respond to deletion requests) rather than read-only accumulation. Informs decisions on how long mail artifacts persist in shared environments.
• Support and QA triage workflows — deleting stale mails and timestamp normalization (YYYY-MM-DD HH:MM:SS) make the viewer usable for correlating customer-reported issues with outbound mail by time.
• Roadmap signal for admin/ops surface area — the split into individual Vue components and a redesigned sidebar icon indicate the maintainer is investing in the UI as a first-class surface, not a throwaway debug page. Reasonable to plan for it as the internal mail console rather than building one.
• Not a decision driver: the SCSS 500-error fix and cosmetic icon change are maintenance; they remove a blocker to adopting the UI at all, but shouldn't move roadmap priorities.

When to Consider This Package

Adopt when:

• You're on Laravel and want zero-infrastructure visibility into rendered mail (who received what, when, with which template) during development, QA, or staging.
• You need a retention control — the new delete route matters if the viewer sits in an environment with real or realistic recipient data and you must purge on demand.
• You want an in-repo tool that your engineers can extend (componentized Vue front end, standard Laravel routes/middleware) rather than a SaaS with per-seat pricing.
• The team is small and the alternative is "nobody checks the emails before they ship."

Look elsewhere when:

• Production mail archiving or compliance is the requirement — this is a viewer, not an auditable mail store. Deletion being a manual UI action is a hint that retention is operator-driven, not policy-enforced.
• You need delivery observability (bounces, opens, provider webhooks, retries). Pair with a transactional provider instead.
• You need granular authorization out of the box; the destroy route makes access control materially more important than in 1.1.x — verify middleware/gate integration before exposing beyond local.

How to Pitch It (Stakeholders)

To executives: "This is a small, free, in-app mail viewer for our Laravel stack — it shows exactly what we send to customers without another vendor contract. The new release adds the ability to delete stored mails, which is the piece we needed before we could responsibly use it anywhere beyond a developer laptop. Low cost, low risk, no new infrastructure."

To engineering: "Version 1.2.0 gives us a delete route and in-tool mail removal, fixes an SCSS compile error that was throwing 500s, splits the Vue tool into components, and normalizes timestamps to YYYY-MM-DD HH:MM:SS. Install it in local and staging behind auth, confirm the destroy route is gated by the same middleware as the rest of the tool, and set a purge expectation for staging data. Not a fit for production archival."