Laravel Sms Laravel Package

Product Decisions This Supports

• OTP and verification flows as a first-class product surface. A driver-based SMS abstraction is the plumbing behind phone-number login, password reset, phone binding, and step-up verification. Whether you ship passwordless login or keep phone as a secondary factor is a product decision this package makes cheap to test.
• Build vs. buy for the notification layer. The package is the "buy/adopt" branch: it supplies the multi-gateway adapter, message object, and facade so your team writes business rules rather than HTTP clients. The real build-vs-buy decision sits one level down — which underlying carrier or aggregator you contract with — and this package deliberately keeps that swappable.
• Multi-provider routing and fallback as a roadmap item. Supporting several channels in one interface is what makes "failover to a secondary carrier," "route by region," or "route by cost tier" a configuration change instead of a re-architecture. Useful when you negotiate carrier contracts or expand beyond a single market.
• China-first go-to-market sequencing. The package's framing is aimed at real-world Chinese carrier requirements (signature and template conventions), which supports a roadmap where mainland delivery precedes international launch.
• Transactional notifications. Order confirmations, delivery updates, payment and security alerts — the predictable, compliance-friendly volume that justifies an SMS relationship in the first place.
• Explicit non-goal to record: marketing and promotional SMS. That's a separate consent, opt-out, and compliance problem; don't let a "we already have SMS" assumption pull marketing scope into this integration.

When to Consider This Package

Consider it when all of the following hold:

• You are on a Laravel version contemporary with the package's 2020 release window (roughly Laravel 6–7, PHP 7.x) and have no near-term framework upgrade forcing the issue.
• Your SMS traffic is China-centric and your candidate carriers match the package's supported drivers.
• You need OTP plus transactional messaging in a small team, and a weekend integration beats a bespoke adapter.
• You are willing to fork and own it: vendor the code, pin the version, and treat it as internal infrastructure with a named maintainer.
• You treat it as a thin adapter, not a platform — the abstraction boundary is the value; the implementation is replaceable.

Look elsewhere when:

• Framework currency matters. No release since January 2020, zero dependents, and a single-maintainer lineage mean no compatibility guarantee with Laravel 9/10/11 and no security-response channel. A stale dependency in the auth path is an audit finding, not a convenience.
• You need international carriers (Twilio, Vonage, MessageBird, AWS SNS) or per-message delivery webhooks and analytics — the value proposition here is regional, not global.
• You need vendor support or an SLA. MIT with no commercial backing means you are the support tier.
• You have exactly one carrier and no failover ambition. A direct carrier SDK plus ~100 lines of your own wrapper is lower total cost than adopting an unmaintained abstraction you must fork anyway.
• Compliance is a hard gate. Chinese SMS requires signature and template registration, real-name verification, and content review. Confirm whether the package handles registration workflow hooks or expects you to manage templates out-of-band — if the latter, budget ops work regardless of package choice.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed Laravel component that shortens the path to phone-based login and transactional notifications, particularly for a China-facing launch. It is not a strategic bet and it is not a platform — it's a replaceable adapter layer. The honest caveat: it was last released in 2020, has essentially no downstream adoption, and is effectively unmaintained. Treat it as code we adopt and then own, not a dependency we inherit and forget. Recommended path: a one-to-two-week engineering spike against our actual Laravel version and target carriers, with a go/no-go that includes an exit cost. If the spike passes, we vendor it internally and budget a small, ongoing maintenance line. If it fails, we fall back to a direct carrier SDK at roughly comparable effort, so the downside is bounded.

To engineering: The architecture is the reason to look — a manager/facade fronting pluggable drivers, message objects, and (typically) queue and rate-limit integration. That's the same shape we'd design ourselves, so forking it is a head start rather than a compromise. The costs are concrete: a frozen 2020 dependency in an authentication-adjacent path, likely PHP and Laravel version pins that will resist framework upgrades, unknown test coverage, and no upstream to send patches to. We own security review, carrier driver validation, and version bumps. Ask for a spike that proves: it installs on our stack, at least two drivers work end-to-end against sandbox credentials, OTP rate limiting and expiry behave, and the queue path doesn't silently drop messages.

Decision requested: approve a time-boxed evaluation with a named owner and a documented fallback, rather than either a blanket adoption or a blanket rejection.