Sms Broadcast Laravel Package

Product Decisions This Supports

• Build vs. buy (really "adopt vs. write"): This package is a thin adapter between Laravel's Notifier/Notification pipeline and one specific vendor, SMS Broadcast (an Australian SMS gateway). It is roughly a single notification-channel class plus config — realistically 1–2 days of engineering to reproduce in-house. Treat it as commodity glue, not a platform dependency.
• SMS vendor selection: The package does not abstract SMS; it commits you to SMS Broadcast. Adopting it is downstream of a vendor decision, not a substitute for one. If the vendor decision is still open, this package should not be on the table.
• Feature scope — transactional SMS in an existing Laravel app: Enables order updates, appointment reminders, staff/ops alerts, and low-volume marketing sends as one more channel alongside mail, database, and push. Lower marginal cost of adding SMS once notifications are already in use.
• Market/roadmap fit: Relevant mainly if you terminate traffic to Australian numbers and are comfortable with SMS Broadcast's sender-ID and route options. For AU/NZ-facing roadmaps it's a plausible last-mile choice; for multi-country products it's a poor fit.
• Explicitly not supported by this package: OTP/verification flows, 2FA, inbound/two-way messaging, delivery-receipt webhooks, templating, rate limiting, or per-message cost controls. If the roadmap needs any of those, budget for them separately — they are the actual work.
• Supply-chain posture: MIT license means you may vendor, fork, and own it. That is the realistic path if SMS Broadcast is already the vendor — pin a commit in-repo rather than relying on Packagist.

When to Consider This Package

Consider it when all of the following hold:

• You are on a supported Laravel version and already use the Notification system for other channels.
• SMS Broadcast is already the contracted vendor, or you have a specific reason to use it (AU termination, existing commercial relationship, sender-ID setup).
• The requirement is outbound, one-way transactional SMS at modest volume.
• You are willing to vendor the source into your repo and accept ownership of it — no expectation of upstream fixes.
• A short integration timeline matters more than a vetted, supported library.

Look elsewhere when:

• You are not using SMS Broadcast. The package's entire value is vendor-specific; there is no abstraction to reuse. Use Twilio, Vonage, AWS SNS, or MessageBird with a maintained channel instead.
• You need verification/OTP, inbound messaging, delivery receipts, or analytics. This package won't carry that; you'd be building on top of a 2-star dependency.
• You need multi-country or multi-vendor routing. Nothing here supports failover or provider abstraction.
• Your org requires security review, an SLA, or a named maintainer. Signal is weak: 2 stars, 0 dependents, a single release in Jan 2024, no evident community vetting. Zero dependents means no one else has stress-tested it in production.
• You need high volume with rate limiting, retries, or cost governance. Laravel queues the send, but throttling and cost controls are yours to build.

Diligence items before committing: confirm which Laravel versions are actually supported, whether it wraps an official SDK or calls the API directly (dependency footprint), how credentials/config are handled, and whether the provider's API surface used here is still current.

How to Pitch It (Stakeholders)

Executive summary: This is a ~100-line connector that lets our Laravel app send SMS through one vendor, SMS Broadcast. It is not a strategic platform component and should not be budgeted or governed as one. The real decision in front of us is the SMS vendor, not the library — once the vendor is chosen, the integration cost either way is small (days, not weeks).

Recommendation: Adopt only if SMS Broadcast is already our vendor and the need is outbound transactional SMS to Australian numbers. In that case, copy the MIT-licensed source into our repo, pin it, and assign an owner — we get the integration for near-zero cost and are not exposed to abandonment. If the vendor decision is open, or we need OTP, inbound messaging, or multi-country routing, skip it and evaluate a maintained provider channel instead.

Risk framing for engineering: Low technical risk (tiny, isolated surface, MIT, easy to replace), moderate operational risk (single unvetted maintainer, 0 dependents, last release Jan 2024 — assume no upstream support), and the real risk is vendor lock-in, since this package hard-codes one provider. Mitigate by keeping the channel behind our own interface so a provider swap stays a small change.