Turbosms Bundle Laravel Package

Product Decisions This Supports

• Channel expansion into the Ukrainian market. TurboSMS is a UA-focused SMS gateway; the underlying business decision (add SMS OTP / transactional alerts for Ukrainian users) is legitimate. This package is only the plumbing — and it is plumbing we would not ship.
• Build vs. buy at the wrapper layer. The package is a thin configuration wrapper around a REST API. It proves the integration surface is small (auth token, sender name, recipients, message body, status lookup). The decision it supports is: buy the vendor service, build the ~100-line client ourselves.
• Platform-fit check — negative. Despite the "PHP package" framing, this is a Symfony 2 bundle, not a Laravel package: no service provider, no facade, no config publishing, no queue integration. For a Laravel codebase this is a rewrite, not an install.
• Upgrade-risk gating. Last release 2016-08-24, Symfony 2.x (EOL 2019), authored against PHP 5.x/7.0. Adopting it would silently pin us to unsupported runtime versions — a decision that shows up 18 months later as a blocked framework upgrade.
• Vendor-continuity signal. 1 star and 0 dependents is not a "hidden gem" — it's the absence of any production validation. Treat it as a reference implementation for the API shape, not a dependency. Nothing here validates TurboSMS's reliability, throughput, or pricing; that requires a direct vendor conversation and a pilot.
• Localization and cost modelling. Cyrillic traffic moves messages from GSM-7 (160 chars/segment) to UCS-2 (70 chars/segment) — a ~2.3x cost-per-message swing. Worth sizing before committing SMS as a default notification channel.

When to Consider This Package

Consider it only in this narrow case:

• You are actively maintaining a Symfony 2.8 / 3.x application already on PHP 5.6–7.0.
• You need TurboSMS as one of several channels and cannot justify even a day of engineering for a first-party client.
• You accept zero upstream maintenance, no security patching, and vendor lock at the bundle layer.

Look elsewhere — or build — if any of the following is true:

• Laravel, Lumen, or modern Symfony (4+/6+/7). Incompatible service container and event model; you get no value from the bundle.
• PHP 8.x. Almost certainly breaks; no maintained fork exists.
• You need operational maturity: queued/async sends, retries with backoff, rate limiting, per-provider failover, delivery-receipt webhooks, idempotency on OTPs.
• You want provider abstraction. A single-vendor wrapper is a one-way door; a SmsSender interface with a TurboSMS driver lets you switch to Twilio/Vonage/Turbosms alternatives without touching call sites.
• Compliance matters. GDPR-style data processing agreements, DPA sub-processors, and data residency should be negotiated with the vendor directly — a 2016 community bundle carries none of that.

Recommended posture: do not add this as a dependency. Read the source for the API call shape, write a first-party driver behind an interface using a maintained PSR-18 HTTP client, and keep the vendor relationship (pricing, SLA, sender-ID registration, UA regulatory requirements) as the actual procurement decision.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a community PHP package for sending SMS through TurboSMS, a Ukrainian gateway. The package is a Symfony 2 add-on from 2016 with no adopters and no maintenance, so it does not fit our stack and carries upgrade risk — but it confirms the integration itself is small. Recommendation: engage TurboSMS directly on pricing and SLA, and spend roughly one engineering day on a first-party client we control. Net cost is lower than adopting the package, and we avoid pinning ourselves to an unsupported framework version.

To engineering (one paragraph): It's a Symfony 2 bundle — no Laravel provider, no facade, no config publish. Last commit 2016, no PHP 8 support, zero dependents. Don't install it. Use it as a spec for the TurboSMS endpoint contract, then implement an SmsSender contract with a TurboSMS driver over Guzzle/PSR-18, queued via Horizon, with retry, idempotency on OTP sends, and receipt webhooks. Keep it behind an interface so the vendor is swappable. Flag the UCS-2 segment-length issue for Cyrillic copy before we quote costs.

Bottom line for the roadmap: SMS-to-Ukraine is a reasonable feature; this package is not the way to ship it. It is a $0 dependency that costs a framework upgrade later — decline, and reuse the knowledge, not the code.