Jet Sms Laravel Package

Product Decisions This Supports

• Localized SMS delivery for the Turkish market. JetSMS is a Turkish SMS gateway; this package plugs it into Laravel's native notification system, so OTP, order confirmation, appointment reminder, and delivery-status messages can reach Turkish carriers without building a custom integration from scratch. Relevant if your roadmap includes TR launch, TR-based users, or TR-language transactional messaging.
• Build vs. buy vs. fork. The integration surface is genuinely small — one notification channel class that maps a Laravel Notification to a JetSMS API call. That makes the honest comparison "adopt as-is" vs. "copy ~200 lines into app/Notifications/Channels" rather than "adopt vs. build a gateway." Given the package's staleness (last release March 2020, 9 stars, 0 dependents), a vendored internal copy is a credible and often preferable path.
• Channel abstraction payoff. Because it implements Laravel's NotificationChannel contract, the product decision is reversible: you can ship SMS with via(['mail','jetsms']) today and swap or add a second provider (Twilio, Vonage, Netgsm, Iletimerkezi) later without touching notification classes. Use this to de-risk the "which SMS vendor" decision, which should be a commercial/ops decision, not an architecture one — keep it that way.
• Feature scoping for 2FA and alerts. Enables a concrete MVP: phone verification and login OTP are the highest-value first use case, and both are single-message, low-volume, high-criticality — a good fit for a thin channel and an easy way to validate deliverability before committing to volume pricing.
• Cost/coverage modeling input. Choosing a TR-local gateway over a global aggregator typically changes per-message cost, sender-ID registration ("originator" rules are stricter in TR), and delivery-report quality. This package forces that conversation early, which is where the real product value sits.

When to Consider This Package

Adopt or evaluate when:

• You are already on Laravel and using (or about to use) the Notification system — this is a drop-in channel, not a parallel messaging stack.
• You have a signed or piloting relationship with JetSMS, or JetSMS is mandated by a local partner/entity. The package is worthless without the vendor account, credentials, and an approved sender ID.
• Your volume and criticality are modest (OTP, transactional alerts), so a thin, unmaintained wrapper is an acceptable failure domain — and you can accept owning the code.
• You can commit an engineer to read the ~single channel class and confirm it matches the current JetSMS API. A 2020 wrapper is a strong signal the vendor API may have moved (auth scheme, endpoint, response format), and the README's config keys may be outdated.
• You treat it as a reference implementation to copy in-house rather than a Composer dependency.

Look elsewhere when:

• Maintenance risk is unacceptable. No release since March 2020, 9 stars, 0 dependents means no community backpressure: no one will file or fix the bug you hit. For a regulated flow (2FA, financial alerts), prefer a maintained channel or vendor-maintained SDK.
• You need features beyond fire-and-forget SMS: delivery receipts/webhooks, inbound SMS, multi-part/Unicode handling, retries with backoff, rate limiting, templating, or per-message observability. This package almost certainly doesn't cover them, and Laravel's queue/retry semantics won't substitute for gateway-level DLR handling.
• You are not Turkey-focused. The opportunity score (0.57) reflects a narrow, geography-bound niche; if your user base is elsewhere, this is dead weight.
• You need a vendor SLA, DPA, or security review — a community wrapper gives you none of that; go direct to the vendor or a first-party SDK.
• You would have to fork immediately anyway. In that case skip the dependency and own the code from day one, with tests and a pinned API contract.

How to Pitch It (Stakeholders)

To executives: This is not a strategic bet — it is a small, MIT-licensed adapter that lets us send SMS through a Turkish gateway using plumbing we already have in Laravel. It unlocks the TR-market OTP and transactional-message use cases with roughly days, not weeks, of engineering. The caveats are equally small and equally clear: the package is a one-person-scale artifact last updated in 2020 with essentially no adoption, so we should budget a short spike to verify it against the live JetSMS API and assume we will own the code. Treat the vendor contract — pricing, sender-ID registration, delivery-report terms — as the real decision; the code is the cheap part and is swappable.

To engineering: One NotificationChannel implementation that translates a Notification into a JetSMS HTTP call. It preserves the via() abstraction, so adding or replacing providers later doesn't touch notification classes — but assume we fork it into app/ rather than depend on it: verify current API/auth, add tests around the request payload and failure path, and decide explicitly how DLRs and retries are handled (the package won't). Two days to validate, not two weeks.