Light Sms Notifier Laravel Package

Product Decisions This Supports

• Vendor selection for SMS, not framework selection. This package is a single-provider connector: it wires Symfony Notifier to LightSms only. The real decision it informs is "is LightSms the right SMS vendor for this traffic?" — evaluated on per-message cost in your target countries, sender-ID rules, delivery-receipt support, and API reliability. The package itself is the cheap part.
• Build vs. buy, scoped honestly. Buying here means ~50–150 lines of HTTP plumbing for free, under MIT, riding Symfony's release train. Building means writing a thin Guzzle/HTTP client with retry and logging. The delta is one to two engineering days — so this is a low-stakes build/buy call, not an architecture decision. Weight it on support and maintenance, not on features.
• Roadmap framing: SMS is a commodity channel. Treat it as one entry in a notification abstraction you own (mail, push, SMS, chat), not as a differentiator. Do not let a provider bridge shape your domain API; wrap it behind your own SmsSender/channel interface so swapping vendors later is a config change, not a refactor.
• Feature feasibility for transactional messaging. Suitable for OTP, login alerts, order/shipping updates, and renewal reminders at low-to-moderate volume — the use cases that justify a "buy" every time. Not suitable as the basis for promotional blasts, A/B-tested campaigns, or anything needing delivery analytics.
• Risk/effort input to a backlog item. The package has 3 stars, 0 dependents, no backer, and release notes that are consistently "no significant changes." That tells you it's parity-maintained plumbing — cheap to adopt, but not something to build product bets on. Plan for the day you replace it.
• Laravel-specific reality check. This is a Symfony bridge, not a Laravel notification channel. In a Laravel shop, adopting it means pulling symfony/notifier + symfony/http-client and bridging DI/config into the container, or calling the transport directly. Your default should be laravel-notification-channels/* or a small in-house channel unless Symfony components are already in your dependency tree.

When to Consider This Package

Adopt if:

• You are on Symfony (or already ship Symfony components) and LightSms is your chosen or incumbent vendor — the DSN (lightsms://LOGIN:TOKEN@default?from=PHONE) makes env-driven config a five-minute job.
• You want SMS wired with zero custom transport code and are content with Notifier's semantics: a send call, no queue, no retries, no receipt handling.
• Volume is low-to-moderate and latency/throughput are non-critical.
• You value a predictable release train and MIT licensing over vendor support. Pin to your Symfony minor (v8.x requires PHP ≥ 8.4; v6.4 LTS covers older runtimes).
• You need a proof-of-concept or MVP shipped this sprint and can afford to revisit the transport later.

Look elsewhere if:

• You are Laravel-first. No native Laravel support, no facade, no notification channel. Bridging Symfony DI into Laravel costs more than writing the channel yourself. Use a Laravel-native channel package or ~150 lines of HTTP client.
• LightSms isn't your vendor, or you need multi-provider routing/failover. Symfony Notifier handles this by composing separate bridge packages — this one won't do it.
• You need capabilities beyond plain text: MMS/rich media, templated messages, registered sender IDs, delivery-receipt webhooks, per-message cost reporting, rate limiting, or retry/backoff. Notifier gives you the send; you own the delivery ops.
• You need an SLA or a support contract. Three stars, zero dependents, and no backer is a bus-factor signal. Budget for trivial fork-and-own if it matters to revenue.
• Compliance is load-bearing — HIPAA, 10DLC/registration, GDPR data residency, or message-content retention rules. That's a vendor and legal question; the bridge offers nothing here.
• Volume is high enough that cost-per-message optimization, custom routing, or a dedicated SMS platform's dashboards outweigh integration convenience.

How to Pitch It (Stakeholders)

To executives — keep it small and honest. "This is a low-cost connector that lets us send SMS through one vendor without writing any integration code. It saves roughly one to two engineering days and carries no license cost. It is not a messaging platform — it sends a message and stops there. The number that matters isn't the package, it's the per-SMS rate and geographic coverage of the vendor behind it. Recommendation: approve as plumbing if the vendor evaluation clears; do not fund it as a strategic capability."

To engineering — state exactly what you get and don't. "We get a DSN-configured LightSms transport for Symfony Notifier: credentials and sender number in env, no custom HTTP code. We do not get queuing, retries, delivery receipts, rate limiting, or any Laravel integration — in Laravel we'd need a service provider and manual container wiring, which likely costs more than a straightforward in-house channel. If we're on Symfony, it's a config line. If we're on Laravel, the honest build/buy answer flips toward writing ~150 lines ourselves. Either way, wrap it behind our own sender interface so a vendor swap is a config change."

Correct the record before it spreads: other Symfony Notifier bridges cover Twilio, Vonage, and similar providers — this package is LightSms-only. Any pitch implying provider-agnostic support from this dependency is wrong, and someone will discover that in production.