Product Decisions This Supports
- Build vs. buy for SMS delivery plumbing: This package is a thin abstraction layer, not an SMS provider. It lets the team avoid building and maintaining per-provider HTTP integrations, credential handling, and response normalization in-house.
- Multi-provider / failover strategy: Driver-based design supports switching providers per request, which is the technical enabler for a fallback or cost-optimization strategy (e.g., primary provider in one region, backup in another).
- Regional go-to-market scoping: First-party drivers are concentrated on Iranian providers (Ghasedak, IPPanel, Kavenegar, Magfa, Melipayamak, SMSIR) alongside MessageBird and Plivo. This signals fit for products serving Iran/MENA; for other markets, driver coverage is the gating question.
- Roadmap input for notifications/OTP: If OTP, transactional alerts, or notification delivery are on the roadmap, this evaluates the "delivery layer" portion of that work and whether it should be a dependency rather than a product-team build item.
- Observability requirements: The package emits SMS-sent events with request and response payloads, which supports delivery auditing, support troubleshooting, and success-rate reporting without custom instrumentation around each provider.
- Vendor-negotiation leverage: A working multi-driver abstraction makes it operationally cheaper to swap providers, which is a useful (if modest) lever in pricing and SLA discussions.
When to Consider This Package
Adopt—or prototype—when most of the following are true:
- The product sends SMS to Iran or another market covered by the listed first-party drivers, and you need more than one provider option.
- You are on PHP 8.3+ and Laravel 13+ today, or can commit to that upgrade path. This is a hard constraint; older Laravel versions are not supported.
- You want a small, MIT-licensed abstraction you can wrap or fork, rather than a full notification/omnichannel platform.
- You need custom driver registration (e.g., an internal or niche provider) and per-request driver switching.
- You are comfortable owning risk for a young, single-maintainer package.
Look elsewhere or build in-house when:
- Maturity risk is unacceptable for a revenue-critical path. 1 star, 0 dependents, a single maintainer, and a very recent release history mean limited production validation and bus-factor risk. For payment-adjacent or compliance-sensitive messaging, prefer a provider's official SDK or a mature multi-channel vendor.
- You need channels beyond SMS (email, push, WhatsApp) under one abstraction—Laravel's notification system or an omnichannel vendor is a better fit.
- Your market is not covered. If you send to the US/EU/LATAM and your provider isn't among the drivers, you'd be writing and maintaining the driver yourself, which erodes the buy argument.
- You require delivery receipts, inbound SMS, short-link handling, or templated campaign management. The feature set described is send-oriented; confirm gaps before committing.
- You cannot pin and audit dependencies. Low-adoption packages warrant version pinning, code review of the driver you use, and a contingency plan to fork.
How to Pitch It (Stakeholders)
To executives: We need SMS for [OTP/transactional alerts], and today that means either building provider integrations ourselves or betting on one vendor. This package is a small MIT-licensed adapter that lets us plug in multiple SMS providers behind one interface, so we can change vendors without re-engineering product code. It's low cost to trial and keeps our options open on price and reliability. The caveat is maturity: it's a young, single-maintainer project with minimal adoption, so I recommend a time-boxed spike and a fallback plan rather than a blind commitment.
To engineering: Driver-based manager for Laravel with per-request driver switching, first-party drivers for several Iranian providers plus MessageBird and Plivo, custom driver registration, HTTP client access, and sent-events carrying request/response data for logging. Requires PHP 8.3+ and Laravel 13+. Proposed next step: a one-to-two-day spike wiring one production-relevant driver, reviewing that driver's code, and confirming test coverage, error semantics, and how we'd fork if maintenance lapses. Success criteria: sends succeed in staging, failures are observable via events, and swapping drivers is a config change only.