Kudisms Notification Laravel Package

Product Decisions This Supports

• Build vs. buy for SMS delivery: Still a thin Laravel notification channel that wires KudiSMS into Laravel's Notification system — the "do we write our own SMS adapter?" question is still answered with "probably not." The 2.0.0 release adds a new decision axis: when you adopt, since it now requires Laravel 12/13 and PHP 8.3+.
• Framework upgrade sequencing: The package's new floor (PHP ^8.3|^8.4, Illuminate ^12.0|^13.0) makes SMS a dependent of your platform upgrade roadmap. If you're on Laravel 10/11, adopting this means either upgrading Laravel first or pinning the abandoned 1.x line. That's a roadmap input, not just an integration detail.
• Feature scoping for transactional messaging: Unchanged — SMS as a config concern rather than a subsystem your team owns, provided your stack meets the new version floor.
• Roadmap sequencing for notification channels: Still shippable alongside mail and in-app in one sprint, but only on Laravel 12/13. On older frameworks, budget the upgrade or defer SMS.
• Vendor selection within a geography: KudiSMS remains a Nigeria-focused gateway; this package keeps it a low-commitment option during discovery. The 2.0.0 vendor move (toneflix-code → toneflix) is a mild continuity signal worth tracking, not a blocker.
• Use cases it unlocks quickly: OTP/2FA, payment and order status notifications, appointment/delivery reminders, account alerts, lightweight broadcasts — unchanged.
• Channel strategy decisions: Laravel's notification abstraction still supports per-user routing across mail/SMS; the breaking rename doesn't alter the abstraction, only the import path.

When to Consider This Package

Adopt it when most of the following are true:

• Your product is built on Laravel 12 or 13 with PHP 8.3+ — this is now a hard requirement, not a preference.
• You're on Laravel 11 or older but have a framework upgrade already planned; sequence the SMS pilot after it rather than pinning a stale package version.
• Your users are primarily in Nigeria / West Africa, or KudiSMS's coverage and sender-ID handling match your audience.
• SMS is a secondary channel — OTPs, alerts, transactional messages — not the core product.
• You want to validate SMS demand before committing to a larger provider or building multi-provider routing.

Look elsewhere — or build it yourself — when:

• Adoption signals still matter: despite the 2.0.0 release and active maintenance, the package shows zero stars and zero dependents. A recent release reduces abandonment risk but does not substitute for community validation. Treat it as maintained sample code, not infrastructure.
• You can't move to Laravel 12/13 / PHP 8.3+: 1.x is effectively a dead branch — no backports, and its namespace (ToneflixCode\...) will diverge from any future fixes.
• You need multi-country or multi-provider delivery: still a single-vendor driver; prefer Twilio, Africa's Talking, Termii, or your own provider-agnostic interface.
• You need delivery receipts, webhook ingestion, retries/backoff, or cost analytics: still provider- and app-level concerns; the 2.0.0 changelog shows tooling and namespace work, not feature expansion.
• Compliance or reliability obligations are high: unchanged — audit vendor and error handling before adopting.
• Your stack isn't Laravel or you don't use the notification system.
• You need channels beyond SMS (WhatsApp, push, RCS) in the same flow.

Migration cost if you already adopted 1.x: 2.0.0 is a hard breaking change — package name, namespace (ToneflixCode\KudiSmsNotification → Toneflix\KudiSmsNotification), and a framework/PHP floor. Budget a composer remove/require, import rewrites, and a republished config file. If you had vendored or forked the driver, you now own a diverged copy and must decide whether to rebase onto 2.x or stay frozen.

Mitigation if you do adopt: MIT license permits forking; wrap the driver behind your own SmsSender interface, add tests around failure and rate-limit paths, and pin the exact version — 2.0.0's rename is evidence that this package will make breaking structural changes between majors.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed adapter that lets our Laravel application send SMS through a Nigerian gateway using our existing notification system. It removes roughly the integration work of adding SMS as a channel, so we can test whether SMS improves verification completion and delivery notifications before committing to a larger contract. The new 2.0.0 release confirms the project is actively maintained and now targets current Laravel (12/13) and PHP 8.3+. Two caveats for the decision: it is a breaking release — package and namespace renamed — so any earlier pilot code needs a short migration; and it raises our minimum framework version, which may pull our Laravel upgrade forward. Still low cost and low lock-in: the license lets us take ownership if the project stalls, and the notification abstraction keeps a provider swap contained.

For engineering: Install toneflix/kudisms-notification:^2.0, configure credentials, add KudiSmsChannel to a notification's via() array. Requires PHP 8.3+ and Laravel 12/13. If migrating from 1.x: composer remove toneflix-code/kudisms-notification, then composer require toneflix/kudisms-notification:^2.0, and update imports and the published config from ToneflixCode\KudiSmsNotification to Toneflix\KudiSmsNotification. Caveats: still no community adoption and a single maintainer, and 2.0.0 changed only tooling, namespace, and version support — no new delivery, receipt, or retry capability. Recommendation: pilot behind our own sender interface, keep the driver swappable, pin the version, and plan to own the adapter if SMS goes to production.