Lob Laravel Package

Product Decisions This Supports

• Omnichannel notification roadmap. Lob is a print-and-mail API (postcards, letters, self-mailers, checks). This channel extends Laravel's existing Notification abstraction to a physical delivery channel, letting you test "paper as a channel" without a new delivery subsystem, queue, or templating stack.
• Build vs. buy vs. wire-up. The real decision isn't "should we integrate Lob" — it's how much to invest. This package represents the cheapest possible option: one channel class, one config block, existing toLob() notification methods. It is a valid prototype-tier investment, not a platform-tier one.
• Feature candidates it de-risks cheaply:
  • Dunning / collections letters and final-notice mail for billing (high compliance value, low volume).
  • Regulatory or legally-required paper notices (insurance, healthcare, financial services) where email isn't sufficient.
  • Address-verification and KYC mailers (a postcard with a code is a cheap proof-of-address).
  • Direct-mail marketing for e-commerce accounts — measurable but discretionary.
• Buy/no-buy signal on the surrounding ecosystem. The laravel-notification-channels org is a known pattern (Slack, Twilio, FCM, etc.). If your team already standardizes on it, this fits the mental model; if not, it adds a dependency for one vendor.

When to Consider This Package

Adopt (spike or fork) when:

• You're prototyping physical mail as a secondary channel and want a working demo in under a day.
• You're on an older Laravel (5.8–7.x) codebase that matches the package's era.
• Volume is low and non-critical — a few hundred letters/month, tolerant of manual retry.
• You're willing to fork it into your org and own it (it's ~one class; the maintenance surface is genuinely small).

Look elsewhere when — and this is the default answer here:

• Laravel 9/10/11 or PHP 8.2+. Last release is 2020-03-07; the illuminate/* constraints almost certainly won't resolve on a modern app. Verify with composer why-not before anything else.
• Mission-critical or high-volume mail. You need Lob webhooks (delivery tracking, returned mail), idempotency keys, retry/backoff, address verification, and template versioning. A 2020-era adapter won't surface those, and you'll rebuild them anyway.
• Checks, certified mail, or bulk campaigns. Go directly to Lob's official PHP SDK behind your own interface — it's actively maintained and covers the full surface.
• Any procurement/security review. 11 stars and 0 dependents means no community validation, no CVE history, no second maintainer. Treat it as unaudited code.

Honest read on the scores: the 0.92 "opportunity" is a gap signal — physical mail is genuinely underserved in the Laravel notification ecosystem — not a quality signal. The low stars, zero dependents, and five-year-old release point the same direction: whitespace, not maturity.

How to Pitch It (Stakeholders)

To executives: "There's a small open-source adapter that lets our Laravel app send physical mail — statements, final notices, verification postcards — through the same notification system we already use for email and SMS. It's a one-day experiment to validate demand and cost per piece. I would not put it in production as-is: it hasn't been updated since 2020 and has essentially no users. Recommended spend: a two-day spike, then a build decision."

To engineering: "It's a thin Notification channel wrapping Lob's API — same shape as our other channels. Expect it to fail Composer resolution on Laravel 10+; if the spike succeeds, we fork it, bump the constraints, add tests for the payload mapping, and wrap Lob behind our own Mailer interface so the vendor and the channel are independently swappable. Budget: ~2 days to fork-and-harden, or ~3 days to skip it and call Lob's official SDK directly — the second option is the safer long-term bet if mail volume justifies it."

Recommendation: Spike, don't adopt. Use it to answer "does physical mail move the metric?" in two days; commit to a first-party, SDK-backed integration only if the answer is yes.