Helo Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for a solved problem: local email inspection. Every Laravel product team needs to see the mail the app actually sends. The realistic options are shared SMTP inboxes, a SaaS sink (Mailtrap/Mailgun sandbox), a containerized sink like Mailpit, or an in-house preview panel. This package is the "consume, don't build" answer for the developer-laptop case: it swaps Laravel's mail transport so every outgoing message — mailables, Markdown mail, notifications, raw Mail::send, queued mailables — lands in a local viewer with HTML/plain-text rendering, headers, recipients, and attachments. Building that internally is multiple sprints against a finished problem. The PM decision is which workflow to sanction, not whether to innovate here.
• A concrete release gate for transactional email. Password resets, receipts, invitations, and digests fail loudly in production and are chronically under-tested because a Mail::fake() assertion only proves that mail was sent, not that it renders. Adopting this turns "does this email render, do links point at the right environment's host, are inline images resolving, are the recipients correct?" into a checkable pre-release step at near-zero tooling cost. That changes QA sign-off criteria and reduces how much verification burden silently stays with whoever wrote the Mailable.
• Cost and data-handling posture for development. Sample-message inspection moves off paid third-party sinks and off real recipient addresses. For a privacy review, contractor laptops, or regulated content in emails, "message content never leaves the developer's machine" is a materially simpler answer than a SaaS data-processing review.
• Roadmap sequencing: framework upgrade readiness. Release 2.1.0 is a compatibility-only update adding Laravel 13.x support — the answer to "does adopting this block our upgrade?" is no. It can be folded into the existing dependency-validation pass rather than becoming a separate review cycle later, and logged on the dependency register as a positive maintenance signal.
• Onboarding and developer-experience investment. "Here's how you see the email the app just sent" being a documented answer rather than tribal knowledge shortens ramp-up measurably, and it's the kind of DX spend that shows up as reduced first-ticket time for new hires.
• Adoption posture: cheap to try, cheap to reverse. This is development-time tooling, not a runtime production dependency — require-dev, one config file, one .env line. Treat it as a team-standard tooling choice with a short pilot, not an architectural commitment. Decision cost is measured in hours, and the integration surface is shallow enough that a swap to Mailpit is measured in minutes.

When to Consider This Package

Adopt when:

• The product is a Laravel application on the built-in mailer, and engineers regularly need to see rendered mail during development.
• Transactional email correctness is business-critical — signup verification, password reset, billing receipts — and the team currently verifies it through shared inboxes, real SMTP accounts, or copy-paste.
• The team is on, or actively planning, Laravel 13.x; 2.1.0 explicitly clears that path.
• You want inspection to stay local: no third-party service receiving message content, no real recipients receiving test mail.
• You want a bounded pilot — blast radius is confined to development environments, so the experiment can be run by one team in an afternoon.
• You accept the operational preconditions: package under require-dev and deployed with --no-dev, MAIL_MAILER=helo never committed to .env.example, CI, Docker, or K8s manifests, and a boot-time guard that throws if the helo mailer is active outside local/testing.

Look elsewhere when:

• You need production email observability or APM — deliverability monitoring, bounce and complaint handling, open/click analytics, delivery audit trails. Different problem, different vendors; this package is not a substitute and shouldn't be pitched as one.
• Your stack is polyglot or non-Laravel. A protocol-level SMTP sink or HTTP proxy is the correct layer; a Laravel-only transport adapter won't cover your Node or Python services.
• You need a formal support contract, SLA, security certification, or guaranteed multi-year support window. This is a ~90-star MIT integration package from a small commercial vendor whose viability tracks the Helo desktop app's continuity. Mitigate with a documented Mailpit fallback and don't build team process that depends on this package's roadmap.
• You need it in CI, containerized preview environments, or over SSH to a remote box. A desktop-dependent capture tool can't run headless; Mailpit remains the answer there. Plan for both and write it down, or you'll field "Helo doesn't work on the remote box" within a month.
• You develop exclusively through Sail/Docker and aren't prepared to configure the endpoint host (host.docker.internal, not 127.0.0.1) — otherwise every send is a connection-refused and a slow registration flow that looks like an app bug.
• Your team is too large or too heterogeneous to enforce the guardrails above. The signature failure mode is silent mail swallowing: if the helo driver is somehow active in staging or production, outbound mail vanishes with no bounce, no error, no log line, and customers never get their password reset. The three cheap defences — require-dev, never committing the mailer value, boot-time environment guard — are non-negotiable preconditions, not nice-to-haves.

How to Pitch It (Stakeholders)

For executives — one paragraph: Transactional email is a high-blast-radius feature we currently verify by hand, and broken password resets and receipts are visible to customers immediately. This package gives every developer a local inbox that captures and renders exactly what the app sends, so "do these emails look right" becomes a pre-release check instead of a hope. It costs hours to adopt, runs entirely on developer machines so no customer data reaches a third party, carries no production runtime dependency, and has already declared Laravel 13 compatibility so it won't block our upgrade path. We recommend a scoped pilot with a documented fallback rather than a strategic commitment.

For engineering — the shape of the decision:

• It's a mail transport, not a framework. composer require --dev beyondcode/helo-laravel, publish config/helo.php, set MAIL_MAILER=helo in your personal .env. Zero application code changes; config/mail.php should never hardcode the driver name.
• The pattern is the env-swap and nothing else. Resist wrapping mailables or forking. Mail::fake() still short-circuits before the transport resolves, so the test suite is unaffected — tests assert that mail was sent to whom; Helo is for the human eye checking what it looks like. Don't try to put it in CI.
• Highest-leverage build on top: an app:preview-mail artisan command that fires the whole transactional catalogue (welcome, reset, receipt) at a fake user, so pre-release verification is one command plus a scroll through the inbox.
• Guardrails are the adoption cost, and they're cheap: require --dev and deploy --no-dev so a stray helo mailer fails loudly with Unsupported mail transport [helo] rather than swallowing mail; never let MAIL_MAILER=helo reach .env.example or any Docker/K8s manifest; add the boot-time RuntimeException if the mailer is active outside local/testing; bind the viewer route to web + auth on shared networks since captured payloads contain live reset tokens.
• Known friction to document once, in onboarding: php artisan config:clear after editing .env, queue:restart for long-running workers, client-not-running produces slow requests rather than just missing mail, and multiple apps share one inbox with no per-app separation.
• Risk acceptance: small vendor, commercial desktop product, shallow integration surface. The fallback is Mailpit for shared, CI, and containerized environments — name it in the same onboarding note. Pin the version, let dependency automation surface releases, and treat any major bump as a review trigger.