Mailbook Laravel Package

Product Decisions This Supports

• Reducing time-to-review on transactional email. Mailbook gives the team a single browsable index at /mailbook of every registered mailable and notification, rendered on demand with no triggering of real user events. As a PM, this converts email review from "ask an engineer to trigger a signup in staging and forward me the screenshot" into a self-serve loop for design, marketing, support, and localisation reviewers.
• Scoping email-related roadmap work more accurately. Because each mail is registered declaratively in routes/mailbook.php, the file becomes a living inventory of the product's outbound communication surface. That is a useful estimation input for work like "rebrand all transactional email," "add German," or "audit every touchpoint for a pricing change."
• Build vs. buy for internal email preview tooling. This is a strong argument for not building an in-house preview harness. The package already covers the non-obvious parts teams usually under-scope: notification support (not just mailables), dependency injection in registration closures, ::to() notifiable binding, categories/groups, and per-mail variants.
• Variant modeling as a product-spec tool. ->variant('1 item', ...) / ->variant('2 items', ...) lets a PM or designer enumerate the states that actually ship (empty state, single item, multi-item, over-limit, trial ending vs. expired). That surfaces missing states before engineering builds them, which is cheaper than fixing them post-launch.
• Localisation and market-expansion decisions. The locales config produces a language switcher in the preview UI. This makes "can we ship this mail in Dutch/German/Spanish?" a demonstrable question rather than a speculative one, and exposes truncation and layout breakage per language before a market launch.
• Approval gates for customer-facing copy. With send / send_to enabled, a reviewer can push the currently selected mail to a real inbox using the app's default mail driver and check it on real clients. This supports a lightweight sign-off step ahead of campaigns or contract-sensitive communications (invoices, dunning, legal notices).
• De-risking QA effort on a low-frequency, high-visibility surface. Transactional email is rarely exercised by normal click-through QA, so defects reach customers directly. A dev-only preview surface raises coverage without adding test-scenario work to the release checklist.

When to Consider This Package

Good fit:

• The application is Laravel (the changelog shows support spanning Laravel 8 through 13) and the team already treats dev tooling as Composer dev dependencies.
• There is a meaningful volume or variety of outbound mail — onboarding sequences, invoices, notifications — where review latency is a real cost.
• Non-engineers (design, marketing, support, localisation vendors) need to see emails without staging credentials or seed accounts.
• The product is multi-locale or about to be, and mail rendering per language needs verification.
• Emails are driven by database models; database_rollback makes factory-based previews safe by rolling back changes after rendering.
• The team wants variant coverage documented and demoable, not just described in a spec.

Look elsewhere or defer:

• Cross-client rendering fidelity is the actual requirement. Mailbook previews in a browser; it is not Litmus or Email on Acid. If the pain is "Outlook 2019 mangles our buttons," this package does not answer that question.
• Deliverability, spam scoring, or inbox placement. Out of scope. Pair with a dedicated deliverability service.
• Non-Laravel stacks. The value is entirely in Laravel's mailable/notification abstractions; there is no meaningful port.
• Small surface area. Two or three static mailables may not justify a new route file and config to keep current — the maintenance cost, while small, is not zero.
• Strict security or compliance posture that resists new application routes. Mitigations exist (routes can be disabled via config, and installation is --dev), but a PM should confirm with security before adding a browsable surface that renders real templates and, if enabled, can send live mail. The send feature in particular should default to off outside local/staging.
• Teams needing hosted, commentable review workflows with non-technical approvers and audit trails. This is a self-hosted developer tool; expect to pair it with screenshots or a shared doc for formal sign-off.
• Bus-factor concerns. Effectively a single-maintainer project (489 stars, no dependents recorded, MIT licensed). That is mitigated by the permissive licence, small footprint, and dev-only scope — an in-house fork is viable — but it should be an explicit, low-severity risk note rather than an assumption of vendor support.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed developer tool that gives us a single, always-current catalogue of every automated email we send to customers. It costs a Composer dev dependency and roughly an afternoon of setup, adds nothing to production runtime, and removes a recurring bottleneck where an engineer must be interrupted to produce a screenshot of an email before design, marketing, or localisation can review it. In practical terms it shortens the review cycle on transactional email, gives us a demonstrable answer to "does this work in German?", and reduces the class of defect that reaches customers directly because normal QA never opens their mailbox. Recommended decision: adopt in staging/local, keep the send-to-inbox feature off by default, and revisit if we later need formal cross-client rendering or deliverability testing, which this tool does not cover.

To engineering: Install as composer require --dev xammie/mailbook, run mailbook:install, and register mailables and notifications in routes/mailbook.php. It supports dependency injection in registration closures, ::to() for notifiables, category/group scoping, per-mail variants, locale switching, and optional DB rollback so factory-created models are safe. Config and views are publishable, routes can be disabled, and it tracks Laravel 8 through 13. It is dev-only, has no production dependency graph impact, and is small enough to fork if upstream stalls. Ask: one owner to seed the route file from the current mail inventory and a decision on whether the send feature is enabled outside local.