Product Decisions This Supports
- Build vs. buy for mail inspection in development. v0.10.0 turns a message table with a viewer into a genuine triage tool: three-column mailbox, sidebar views (Inbox / Unread / Spam by score), people list, type-ahead search with highlighting,
j/k navigation, and / to search. That is a credible replacement for "everyone shares a seed inbox" or "spin up Mailhog and copy-paste" workflows, so the decision is whether your team's debugging time is worth adopting a package versus maintaining an internal tool.
- Where mail debugging lives in the roadmap. The Spam view (highest score first, green below 2, amber from 2, red from 5) makes spam scoring a first-class, visible signal rather than a hidden header. If deliverability or spam-filter behaviour is on your roadmap, this gives you an inspectable surface without instrumenting anything yourself.
- Scope for a "developer console" surface. The package now has its own icon in the tab, its own responsive layouts (tablet rail of icons, phone split list/message), and in-page confirmations. It is settling into a self-contained product surface you can point engineers and QA at, rather than a debug page bolted onto the app.
- Extensibility decisions hinge on the new address API.
addressesFor(AddressRole::To), sender(), envelopeSender(), plus display() / emails() / includes() on the returned collection, is a real read API over a normalised mailroom_addresses table. This is the point at which the package becomes something you can build on (custom reporting, "who did we email" checks, test assertions) instead of just look at.
- Prioritising who the tool is for. Rows now lead with the recipient and an avatar, because in a dev mailbox the sender is almost always the app itself. That is a deliberate product opinion: the primary user is a developer verifying outbound mail, not a person reading a conversation. Align internal expectations accordingly.
- QA and demo use cases. "Delete returns you to the list you came from, with its search, filters and page" and confirmations that name the message or count reduce the cost of repetitive QA passes and live demos, and reduce the chance of a mis-click wiping evidence mid-investigation.
- Scheduling the upgrade. The release is a breaking change: a required
php artisan migrate moves addresses into mailroom_addresses, and the from/to/cc/bcc/reply_to/envelope_recipients/envelope_sender columns, their model attributes, and formatAddressList() / formatAddress() are all removed. Plan an upgrade window, and audit any custom queries, dashboards, exports or tests touching those columns before you commit. The migration is reversible, which lowers the risk of a bad rollout.
When to Consider This Package
Consider it when:
- You have a Laravel/PHP application that sends mail, and engineers need to see what was actually sent without configuring real inboxes or a third-party capture service.
- You want captured mail to live in your own database, viewable inside the app, with no extra infrastructure to run and no mail content leaving your environment.
- You need triage at volume: searching by address or name, finding everyone who appears on a message, spotting the worst spam score first, and keyboard-driven browsing. The v0.10.0 UX assumes mailboxes with more than a handful of messages.
- Spam scoring is part of your quality bar and you want it surfaced, colour-coded, in the list, tab row and spam pane, without writing a UI for it.
- You want a stable read API for addresses to power tests or internal tooling (
addressesFor(...), sender(), envelopeSender()), and are willing to query mailroom_addresses directly where the old columns used to suffice.
- You are pre-1.0 tolerant: at 0.10.0 the package is still shipping breaking schema and API changes, and this release removes columns and methods outright.
Look elsewhere when:
- You need production mail delivery, deliverability, bounce handling or an ESP integration — this is a development inspection tool, not a mail transport or a transactional provider.
- You need a real email client: IMAP sync, folders, threading, composing and replying to real people. The "mailbox" here is a view over captured messages, not a mail store you operate.
- Your team cannot absorb a schema migration and API removal on a dev tool right now, or you have significant internal code built on the pre-0.10.0 message columns.
- You need long-term retention, retention policy controls, or audit-grade record keeping of captured mail; a development capture table is the wrong place for that.
- You want a fixed, supported API contract. Pre-1.0 releases with removals mean you should budget for periodic upgrade work.
How to Pitch It (Stakeholders)
For executives: This is a free, in-app developer tool that shows every email our application sends, so engineers and QA can verify content, recipients and spam scores in seconds instead of setting up test inboxes or asking for screenshots. The new version makes it substantially more usable — searchable mailboxes, a "who did we email" people view, keyboard navigation, and phone/tablet layouts — which cuts routine debugging and demo-preparation time. There is no licence cost and no new infrastructure.
For engineering: v0.10.0 is a meaningful upgrade with a required php artisan migrate that normalises addresses into mailroom_addresses. The old address columns and the formatAddressList() / formatAddress() helpers are gone; use addressesFor(AddressRole::...), sender(), envelopeSender(), and display() / emails() / includes() instead, and query mailroom_addresses wherever you used to query the message columns. It also fixes real search bugs (matches on "address"/"name", non-ASCII names like "Müller", % and _ on SQLite and SQL Server, case sensitivity on PostgreSQL) and makes delete return you to the filtered list you came from.
Recommendation: Schedule the upgrade as a small, contained piece of work — audit for queries against the removed columns, run the migration in a throwaway environment first, verify rollback, then ship. Treat it as developer productivity investment, not customer-facing scope.