Smtpfast Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for transactional email delivery. This package makes the "buy" option a one-line config change: MAIL_MAILER=smtpfast plus an API key, with existing Mailable and Notification classes untouched. That reframes email infrastructure from an engineering project into a vendor evaluation — the PM decision becomes commercial and operational, not architectural.
• Roadmap sequencing for email-dependent features. Password resets, receipts, digest emails, and lifecycle notifications all depend on delivery reliability. Because integration cost is near zero, delivery can be de-risked early in a milestone rather than at the end.
• Deliverability feedback as a product input. Optional webhook verification enables ingesting bounce/complaint/delivery events. That supports decisions like suppressing dead addresses, gating marketing sends on engagement, and surfacing "we couldn't reach you" states in the UI — things that are usually invisible until support tickets appear.
• Platform surface beyond mail. The bundled SMTPfast PHP client exposed as a singleton and facade means the same dependency can serve non-mail API calls (send status, account data). Worth flagging in the roadmap as a potential second use case, but not a reason to adopt on its own at v0.1.0.
• Migration and exit-cost planning. Because Mailables are unaffected, reverting to SMTP/SES/Postmark is an env change, not a code change. This lowers the cost of a wrong vendor choice and is a legitimate argument for trying a younger provider.
• Stack-currency decisions. Support for Laravel 12 and 13 on PHP 8.2+ signals alignment with current and next-major Laravel. It also means the package is not an option if the product is pinned to Laravel 10/11 — a relevant input if a legacy app is in scope.

When to Consider This Package

Consider it when:

• The application is on Laravel 12 or 13 with PHP 8.2+, and mail is standard Laravel Mail/Notification usage with no custom transport internals.
• You want to offload SMTP relay operations (IP reputation, retries, queueing at the edge) without adopting a full ESP suite or writing a transport.
• You need delivery event ingestion (webhooks) to drive list hygiene or in-product messaging, and want that verification handled rather than hand-rolled.
• You are running a time-boxed trial or MVP where the ability to swap providers cheaply matters more than a multi-year vendor commitment.
• You want a single vendor boundary covering both mail sending and a supporting API client, with minimal glue code to maintain.

Look elsewhere when:

• Vendor maturity is a hard requirement. v0.1.0 is a first release; there is no public track record of stability, incident history, or breaking-change policy. Regulated, high-volume, or revenue-critical mail flows should not be first adopters.
• Compliance and data residency (SOC 2, HIPAA, GDPR data processing terms, regional storage) are gating — these are unaddressed in the release notes and must be verified contractually before any pilot.
• You need ESP-grade features: template management, journey/drip builders, A/B testing, dedicated IP warmup, granular analytics. This is a transport, not a marketing platform.
• You need self-hosted or air-gapped mail, or a multi-provider failover strategy at the transport layer — a single-provider driver concentrates that risk.
• You need a supported SDK contract: SLAs, support tiers, deprecation windows, or an LTS guarantee. None of that exists at 0.1.x.
• Your team requires production-grade observability (per-message tracing, retry introspection) available today; the package exposes a client and webhooks but no evidence of dashboards or metrics integration.

Recommended gate: a bounded pilot on non-critical transactional mail (password resets, receipts) with the API key stored in the secret manager, a documented env-var rollback, and an explicit review of the vendor's security and data-handling posture before expanding scope.

How to Pitch It (Stakeholders)

For executives: We can move transactional email onto a managed provider with a configuration change rather than an engineering project — no rewrites of existing email code, and a one-line rollback if it doesn't work out. The trade-off is vendor maturity: this is a first release (v0.1.0), so the recommendation is a contained pilot on non-critical mail, not a wholesale migration. Approving a pilot costs little and buys us a validated exit-cost estimate for our current email setup.

For engineering: Drop-in Laravel mail transport — set MAIL_MAILER=smtpfast and SMTPFAST_API_KEY, and existing Mailables and Notifications continue to work unchanged. Ships the SMTPfast PHP client as a singleton and facade, plus optional webhook signature verification for delivery events. Targets Laravel 12/13 on PHP 8.2+. Scope of work is configuration, secret management, and webhook endpoint wiring — no transport code to own. Two caveats to plan around: pre-1.0 versioning means pinning the dependency and expecting breaking changes, and webhook consumption needs an idempotent, verified endpoint before we depend on it.

For the wider business: Lower operational burden for the team that currently owns mail deliverability, faster enablement of email-dependent features on the roadmap, and a vendor decision that remains reversible — which is the main reason it's reasonable to evaluate a young provider now rather than after a larger commitment.