Why we built Lettr on Laravel

Lettr, our email API, is a Laravel application, and our Laravel SDK is the most direct integration we offer. Why? Three reasons: Laravel's defaults are the decisions an experienced team would have made anyway, its packages are built by people who run them in production, and its conventions make a Laravel codebase one of the easiest to work in, for a new developer and, increasingly, for a coding assistant. We have worked in Laravel since Laravel 4, released in 2013; aside from Lettr, we've built Topol, Ecomail, and DMARCeye on it. This article is about what has kept us there.

Defaults you don't have to fight

A serious Laravel application can reach production quickly, because the defaults are the ones an experienced team would have picked anyway. Sessions, queues, validation, migrations, testing, mail: these are decisions every web application has to make, and Laravel has already made them in ways that will not need replacing as traffic grows.

That sounds like a beginner's benefit. In practice it is a senior one: it means the hours go into the thing that makes your product different instead of into the same infrastructure every product needs and no customer ever sees.

Authentication is a good example. There is an official starter kit that gives you registration, login, password reset and two-factor out of the box, and underneath it the same pieces are available separately: Fortify for the backend logic, Sanctum for API tokens, and Passport when you need OAuth2. Start with the default and drop down a layer only when requirements demand it. Most applications never need to.

Mail is the case we care most about

Laravel's mail layer is driver-based and sits on Symfony Mailer, so a transport is a class plus a config entry. Swapping where your mail goes is a configuration change, not a refactor.

That is why our SDK, which covers Laravel 10 through 13, registers itself as a mail transport rather than asking you to rewrite anything:

composer require lettr/lettr-laravel
php artisan lettr:init

MAIL_MAILER=lettr
LETTR_API_KEY=...

Existing Mailables keep working unchanged:

use App\Mail\WelcomeEmail;
use Illuminate\Support\Facades\Mail;

Mail::to('user@example.com')->queue(new WelcomeEmail());

There is a second reason mail and Laravel fit together. Sending at volume is a queue problem (retries, backoff, failed job handling, rate limiting), and Laravel includes all of it, with Horizon on top for visibility. We send through Laravel's own queue system rather than replacing it, and so does every application that integrates with us.

Packages built by people who run them

The package ecosystem is the part of Laravel we rate most highly. The good packages are built by people who also run them in production, so a package's failure modes tend to be found by its authors before they reach your application.

Some of what we run in Lettr:

• pestphp/pest runs our whole test suite: parallel runs, readable assertions, and the browser tests we use for the editor.
• laravel/cashier handles Stripe billing for Lettr's plans. Subscriptions, proration and webhook handling would otherwise be weeks of work and a long tail of edge cases that only show up in production.
• bref/bref deploys the whole Lettr application to Lambda. Running a full Laravel app serverless used to be a project in itself; with Bref it is a deployment target, and we get the scaling characteristics an email API needs without operating servers for it.
• laravel/boost and laravel/mcp are the AI tooling. More on this below.

Not all of the good work is first-party. Spatie has open-sourced a great deal of what they run in their own client work, and it holds to the same pattern. We run their packages for permissions, media handling, backups and health checks, four problems we have never had to solve ourselves. Open any serious Laravel composer.json and you will find several of theirs in it.

The conventions turned out to be an AI strategy

The same conventions that make Laravel readable for a new developer make it readable for a coding assistant. An assistant working in a Laravel codebase can rely on the same file layout, the same naming, the same idioms it has seen in every other Laravel codebase, and on documentation thorough enough to reason from. There is a right way to do most things and it is written down.

Laravel has built for this rather than resisted it. Boost gives an assistant a first-party view of your application and version-correct guidelines instead of whatever it half-remembers about Laravel 8. The MCP package lets you expose your own application to an assistant as a set of tools, which is how we let you run Lettr from an assistant.

This is one reason we expect Laravel to still be a sensible choice in a decade. The bet on convention over configuration, made back in 2011, turns out to have produced exactly the property that makes a codebase legible to a machine. The other reason is the community.

The community is the reason the framework lasted

Laravel is community-driven in a way that shows in ordinary work: the answer to a specific problem usually comes from someone who has hit it themselves.

None of this happened by accident. Taylor Otwell and the Laravel team have given the framework continuous direction for over a decade, which is rare in open source. Most projects that age this well have already drifted, fragmented, or been abandoned by their original maintainers. Laravel's releases arrive when the core team says they will, the direction is consistent, and the people making those calls are the same people running Laravel applications in production. Jeffrey Way and Laracasts deserve a large share of the credit too, having taught Laravel continuously since the framework's early years.

The clearest evidence of this stewardship is longevity. We have carried applications from Laravel 4 to Laravel 13. Some of it was painful, and the 4 to 5 transition was close to a rewrite. What matters is what came after: a predictable annual release, upgrade guides written in advance, majors that are deliberately boring, and tooling like Laravel Shift for the mechanical parts. Topol and Ecomail have both been through it and are both still in active development.

For infrastructure like email, this matters more than any individual feature. We are asking customers to depend on us for something they cannot afford to have break, and we would rather make that promise on a foundation that has already survived its own major versions.

This is also why we sponsor Laravel-focused events. Lettr is a Platinum sponsor of Laravel Live Denmark and Ecomail is a Gold sponsor. We built commercial products on top of this community's work, and funding its events is one way to contribute back.

FAQ

Bottom line

Laravel's packages and its people make it easier to build on and more future-proof than most alternatives. That is why Lettr runs on it, and why our Laravel SDK is the integration we point developers to first.

For a Laravel application that needs an API for transactional and marketing email, including the drag-and-drop editor behind Topol, create a free Lettr account and start with the Laravel quickstart.