Jusibe Laravel Package

Product Decisions This Supports

• Build vs. buy for SMS delivery in a Laravel codebase: this package is a thin notification channel adapter for Jusibe, a Nigerian SMS gateway. It lets the team send transactional SMS through Laravel's existing Notification abstraction instead of building and maintaining a custom HTTP client, retry logic, and config wiring.
• Channel expansion on an existing notification surface: if the product already uses Notifier/Notification classes for email or in-app alerts, adding SMS becomes a configuration and one-class change rather than a new subsystem — a measurable reduction in engineering scope for OTP, order-confirmation, and payment-alert flows.
• Market/geo expansion decisions: relevant primarily if Nigeria (or Jusibe's coverage footprint) is on the roadmap as a target market. It informs whether local SMS aggregation is bought from a regional provider versus a global aggregator (Twilio, MessageBird, Africa's Talking).
• Roadmap triage / technical-debt review: the 2020 last release, Laravel 5.3-only targeting, 8 stars, and 0 dependents are themselves a decision input — this is a signal to exclude it from new-build planning and treat it as legacy-only, or as a template to fork rather than adopt.
• Vendor concentration risk assessment: choosing a single small regional gateway for a critical path (OTP, transaction alerts) is a product-availability decision, not just an engineering one; this package's existence makes that dependency cheap to add, which raises the importance of an explicit fallback decision.

When to Consider This Package

Consider it only when all of the following hold:

• The product is a Laravel application pinned to 5.3 (or you are prepared to verify/port compatibility to your version — the adapter is small, so porting is realistic).
• Jusibe is already the chosen SMS vendor, typically for Nigerian delivery, pricing, or sender-ID reasons.
• SMS is non-critical or low volume — OTPs with a fallback, low-stakes notifications — not the sole channel for revenue-critical transaction alerts.
• The team accepts maintenance ownership: no releases since April 2020, no dependents, and near-zero community surface mean you will be the maintainer of any fix.

Look elsewhere when:

• You are starting a new build — prefer an actively maintained first-party or well-adopted channel, or write a ~100-line custom channel against the vendor's HTTP API.
• You need delivery receipts, retries/backoff, rate limiting, templating, or multi-provider failover — none of which a thin channel adapter provides.
• You are on Laravel 9/10/11 and unwilling to fork and test.
• SMS is on the critical path for authentication or payments, where vendor and package abandonment risk is unacceptable.
• You operate across multiple countries and need a global aggregator rather than a single regional gateway.

How to Pitch It (Stakeholders)

For executives: This is a small, free (MIT), community-built connector that would let us send SMS through Jusibe using code patterns we already have. The upside is speed and near-zero license cost if Nigeria is a target market. The risk is material: the package has had no updates since April 2020, targets Laravel 5.3, and has essentially no adoption — meaning no one else is validating it and we would own any breakage. Recommendation: do not adopt for new work. If Jusibe is a strategic vendor, budget a small spike to fork the adapter or write our own channel against the vendor API, and pick a primary/secondary SMS vendor pair before committing to any single regional gateway.

For engineering: Treat this as reference implementation, not a dependency. The integration surface is a single notification channel class plus config — roughly a day to reimplement against the current Laravel notification API with the retry, logging, and provider-fallback behavior we actually need. If we do pull it in, pin it, wrap it behind our own SmsSender interface, and add a test double so a vendor switch is a one-file change.