Touch Sms Laravel Package

Product Decisions This Supports

• Feature scoping for SMS notifications. This package lets a Laravel app send SMS via the Illuminate\Notifications system with a toTouchSms() method or an on-demand route. That makes "add SMS OTP / transactional alerts / appointment reminders" a thin, shippable feature rather than a platform project — realistically days, not a sprint, assuming TouchSMS is already an approved vendor.
• Vendor selection: TouchSMS vs. Twilio / Vonage / AWS SNS / MessageBird. The integration cost of a provider is a real input to the buy decision. This package lowers the marginal cost of choosing TouchSMS specifically (an AU-focused gateway), which matters if the roadmap includes AU/NZ market entry, local sender-ID registration, or data-residency preferences.
• Build vs. buy at the channel layer. The alternative is writing your own notification channel plus HTTP client (~a few hundred lines plus tests). Adopt this if your needs are one-way transactional SMS. Build your own (or pick a heavier SDK) if you need delivery receipts, inbound messaging, MMS, templated/registered sender IDs, bulk campaigns, or multi-provider failover.
• Architecture decisions around provider abstraction. Because it plugs into Laravel's Notifiable contract, notifications stay provider-agnostic. That supports a product-level hedge: pick TouchSMS now, keep the option to swap providers later without rewriting notification classes.
• Upgrade-path planning. Release 2.1.0 adds Laravel 12.x support (a compatibility-only change, no new features or breaking changes). That keeps the package viable for teams on or moving to Laravel 12, and removes "framework version" as a blocker in a modernization roadmap — but it does not change the package's underlying capability surface.
• Prioritization signal, not a platform bet. With 5 stars and 0 dependents, this is a convenience wrapper. It should be scoped as an enabler for a feature, never as a strategic dependency in its own right.

When to Consider This Package

Adopt when:

• You are already on TouchSMS, or TouchSMS is a finalist in an active vendor evaluation (AU-based provider, local compliance/sender-ID needs).
• Your stack is on a supported Laravel version — including Laravel 12.x as of 2.1.0 — and already uses Illuminate\Notifications; the integration is idiomatic and low-ceremony.
• Your SMS volume is modest, one-way, transactional, and you want near-zero operational overhead.
• You are comfortable being the de facto maintainer of the integration if the vendor's API shifts — you should pin the version and wrap the channel behind your own abstraction.

Look elsewhere when:

• You need inbound SMS, delivery webhooks/receipts, MMS, campaign/bulk tooling, or templated sender-ID management — this is a send-a-message channel, not an SMS platform.
• You need multi-provider failover for a critical path (OTP, security alerts). This package gives you exactly one provider, and the community-validation signal is weak; a critical path deserves a fallback provider or a higher-support vendor.
• You require enterprise SLA, vendor support contracts, or a large maintainer community. Stars and dependents are near zero, and if you are not on Laravel, the package is irrelevant.
• You are outside the AU/NZ footprint and have no reason to prefer this gateway over a globally dominant one with a mature Laravel ecosystem.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed connector that lets us send SMS through our existing Laravel notification system without building or operating new infrastructure. It converts "add SMS alerts/OTP" from a platform project into a scoped feature — roughly days of engineering, no new vendor platform to run. The latest release (2.1.0) is a maintenance update that adds Laravel 12 support, so it stays compatible as we upgrade the framework — no new functionality, no migration work. The trade-off stands: it's a low-adoption package, so we treat it as a convenience wrapper and keep our notification code provider-agnostic so we are not locked in.

To engineering: It's a NotificationChannel implementation plus a bound HTTP client — nothing exotic. Version 2.1.0 is a non-breaking compatibility bump adding Laravel 12.x support; pin it and upgrade alongside the framework. We'll wrap it behind our own thin interface so notification classes never reference TouchSMS directly, and add a second provider behind that interface for anything security-critical (OTP, account alerts). The main risks remain single-maintainer/small-community exposure and provider-side API changes; both are contained by the wrapper and a fallback path.