Sms Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging infrastructure: shetabit/sms provides a driver-based abstraction over SMS providers on top of Laravel's notification/manager patterns. Adopting it lets the team skip building (and maintaining) a provider-agnostic sending layer, config schema, and per-gateway payload handling in-house.
• Multi-provider strategy / vendor de-risking: Because each gateway is a swappable driver selected via config, the roadmap can include provider failover and per-region routing without re-architecting application code. v1.1.0's addition of an IPPanel driver is a direct, concrete win here — it materially expands coverage for the Iranian/MENA market, where IPPanel is a common provider alongside the package's existing gateways.
• Regional go-to-market: If the product roadmap includes Iran or Persian-language markets, this release is the trigger that removes a blocker (previously you'd have had to write and own a custom driver). That makes the package viable for a market expansion decision rather than a "someday" item.
• Use-case fit: OTP/verification codes, transactional alerts (order status, payment, shipping), and low-volume notification flows. These are the flows where a thin abstraction beats a bespoke integration.
• Cost/leverage negotiation: Holding two or more supported drivers means pricing and reliability conversations with a single SMS vendor are no longer single-threaded.
• Scope boundary: This package is a sending abstraction, not a campaign platform. It should not be positioned as covering marketing automation, segmentation, A/B testing, or delivery analytics — those remain separate build/buy decisions.

When to Consider This Package

Adopt when:

• You are on Laravel and want SMS sending to look like any other Laravel service (config-driven, container-resolved, queue-friendly).
• You need more than one SMS provider, or expect to switch providers without touching business logic.
• Your target market includes Iran/MENA and IPPanel (or one of the package's other gateways) is your provider — the new driver is exactly the reason to re-evaluate now.
• Your message volume and criticality are moderate: OTP and transactional notifications where a retry/fallback policy at the application layer is acceptable.

Look elsewhere or proceed with caution when:

• Maturity risk: This is a 1.x package at v1.1.0 with a small contributor base and a single new external contributor in this release. Expect API surface to move before 2.0 — pin versions explicitly and wrap usage behind your own thin service/interface so an upstream change is a one-file fix.
• Single-maintainer / bus-factor risk: Assess maintenance cadence and issue responsiveness before making it load-bearing for revenue-critical OTP flows. Have a fallback: a driver is a small class, so forking is cheap — confirm that's acceptable to engineering before adoption.
• Enterprise requirements: No evidence of SLA, delivery-receipt guarantees, audit logging, or provider-side failover. If you need guaranteed delivery semantics, throughput commitments, or compliance evidence, a commercial CPaaS with a supported SDK is the safer call.
• Omnichannel needs: If the roadmap requires SMS + email + push + WhatsApp under one orchestration layer with unified templates and analytics, this is a sending driver, not an engagement platform. Evaluate a broader notification product instead.
• Provider coverage gaps: Verify your specific gateway is supported (or budget a day to write the driver). Coverage is community-driven, not exhaustive.

Recommendation: Trial in a non-critical path (internal alerts or a staging OTP flow) behind an internal interface, with a pinned version. Promote to production OTP only after confirming provider coverage and maintenance responsiveness.

How to Pitch It (Stakeholders)

To executives: We can add SMS — verification codes and transactional alerts — without building or owning messaging infrastructure. This release adds support for IPPanel, a major provider in the Iranian market, which unlocks that region without custom engineering work. Because the package abstracts the provider, we are not locked in: switching vendors becomes a configuration change and a price negotiation, not a rewrite. Cost is minimal (open source) and time-to-first-message is days, not sprints. The main caveat to acknowledge up front is maturity — it's an early-1.x, small-community package, so we'll pin the version, isolate it behind our own interface, and pilot it on non-critical notifications before it touches revenue-critical flows.

To engineering: Laravel-native, driver-per-gateway, config-selected. v1.1.0 adds an IPPanel driver — one new class implementing the existing driver contract, no breaking changes to the public API. Integration cost is low; the real work is on our side: wrap it in an internal SmsSender interface so upstream churn before 2.0 doesn't leak into the codebase, pin the version, and define retry/fallback behavior at the application layer since the package doesn't provide delivery guarantees. Also confirm our target provider is covered and check issue-tracker responsiveness before we make it load-bearing for OTP.