Skebby Bundle Laravel Package

Technical Evaluation

Architecture fit. v4.0.0 resolves the ambiguity in the prior assessment: this is definitively a Symfony bundle targeting Symfony 5.4 and 6.0, not a Laravel package. It ships no Laravel service provider, no publishable config, no facade, and no kernel-compatible bootstrapping. Laravel does not boot Symfony bundles — it consumes individual Symfony components underneath its own container — so installing this into a Laravel application yields either a dead dependency or a hand-rolled bridge that reimplements the bundle's extension loading. The capability delivered also remains narrow and now explicitly scoped: the release notes name only the User's API (account/auth) and the SMS Send API (single send path). No delivery receipts, no webhooks, no scheduling, no batch or address-book surface. The abstraction value over a ~100-line internal HTTP client is still marginal, and the bundle framing adds integration cost rather than removing it.

Integration feasibility. Low complexity, low value — unchanged, and now confirmed rather than hypothesized. SMS dispatch remains a well-bounded problem: credentials, recipient list, sender alias, body, response with message ID. A direct Laravel Http client gives full control over payload shape, retry semantics, unicode segmentation, and logging. Adopting the bundle means taking on a Symfony DI extension, its service definitions, and its Guzzle wiring purely to make one outbound call. The "Fixes dependencies" line is the only signal about maintenance hygiene, and it is not auditable from release notes alone — no changelog detail, no version delta.

Technical risk. Still high, but the risk profile has shifted from abandonment to wrong framework plus unverified breaking change:

• Framework lock-in confirmed. Symfony 5.4|6.0 is a hard constraint. If our applications are Laravel 10–12, this package cannot be a first-class dependency regardless of its quality. That alone closes the evaluation.
• Major version bump with no migration notes. v4.0.0 implies breaking changes against 3.x, but nothing documents what moved. Any prior spike code or reference snippets from the 2021 release are now unreliable as a payload contract reference — the very use we previously allowed it.
• Adoption signal unchanged. Single maintainer, negligible stars/dependents, no visible CI, no CVE disclosure path. A dependency with outbound messaging credentials and account-level User API access deserves more scrutiny than this repository invites.
• Scope is send-only. Confirming User + SMS Send API means the operational gaps identified earlier stand: no delivery-report collection, no unicode/GSM-7 vs UCS-2 handling evidence, no concatenation billing awareness, no rate-limit awareness.
• API generation. The release now points at developers.skebby.it REST documentation, which is an improvement over a presumed legacy gateway surface — but a documented link is not an implemented contract, and no tests are cited.

Key questions.

1. Is this a Symfony bundle or a Laravel package? Answered: Symfony bundle, Symfony 5.4|6.0. Does any team here run Symfony, and if not, is this evaluation closed?
2. What specifically broke between 3.x and 4.0.0, and does the bundle cover the current REST SMS Send API in full or a subset?
3. Does it handle delivery receipts/webhooks, sender aliases, scheduled sends, and unicode/concatenation correctly? (Release notes mention none of these.)
4. Is there any test suite, and does it mock the HTTP layer?
5. What dependencies were "fixed," and do they resolve cleanly on PHP 8.2–8.4?
6. Is Skebby a mandated vendor, or a convenience choice? (If mandated, we still don't need this package.)
7. Are there consent/GDPR logging requirements around SMS that the package would need to satisfy?

Integration Approach

Stack fit. Confirmed mismatch. Treat the package as reference documentation for the Skebby REST payload contract only — and even then, verify against live vendor docs rather than the bundle, since v4.0.0 changed dependencies without a changelog. Do not install it in a Laravel application.

Migration path. Unchanged, and now better justified: introduce a framework-agnostic boundary and keep the vendor behind it.

• Define App\Contracts\SmsSender with a single send(SmsMessage $message): SmsResult method.
• Implement SkebbySmsSender using Laravel's Http client, credentials from config/services.php backed by environment/secret manager — never committed.
• Bind the interface in a service provider; provide a FakeSmsSender for tests (or use Http::fake()).
• Persist every attempt to an sms_messages table with provider message ID, segments, cost estimate, status, and correlation ID.
• Dispatch through queued jobs with exponential backoff, idempotency keys, and a dead-letter path.
• Read Skebby's User API docs directly for any balance/credit checks we want; do not proxy them through a Symfony service.

If a team still wants a spike, install it only behind the interface in a throwaway branch and delete it before review. Do not let it leak into domain code, and do not treat it as a supported path.

Compatibility. Run composer why-not leandro980/skebby-bundle against our actual PHP/Laravel matrix before any spike — expect it to fail on Symfony version constraints under Laravel 10+. Verify the Skebby contract against a sandbox account, not production.

Sequencing.

1. Vendor account + sandbox credentials; direct curl to Skebby's current REST Send API to confirm the live contract (0.5 day).
2. Interface, DTOs, config, and fake (0.5 day).
3. Real implementation, queue integration, retries, persistence (1 day).
4. Observability: structured logs, failure alerts, cost/segment tracking (0.5 day).
5. Optional: skim the bundle's request builder for edge cases we missed, then discard.

Total: ~2.5 engineer-days for a solution we own outright, versus an indefinite fork obligation on a framework we don't run.

Operational Impact

Maintenance. Effectively zero upstream maintenance for our purposes, with a new twist: the package is now maintained for a different framework, which is worse than dormant — it will accrue Symfony-version churn we can never consume. Adopting it in a Laravel codebase means either a permanent shim or a fork that must be re-rebased on every upstream release. A single-maintainer package with a four-year gap followed by one major bump is a bus-factor of one with no succession plan.

Support. No community, no issue triage, no security advisory process. Skebby's own vendor support remains available, but debugging sits one opaque layer removed from the wire — the worst position for a messaging incident. Internal ownership of a small client is strictly cheaper to support.

Scaling. SMS throughput is vendor-bound, not package-bound. Skebby enforces per-second and per-day limits, and a send-only wrapper has no rate-limit awareness, no batching, and no backpressure. We must supply queuing, concurrency caps, and throttling ourselves regardless of client — which further erodes the package's value.

Failure modes. Anticipate: silent drops where the vendor returns a non-2xx the wrapper swallows; auth failures surfacing as generic Symfony exceptions that our Laravel handler won't map; unicode messages silently split into multiple billable segments; no retry on transient 5xx or timeouts; delivery receipts uncollected, leaving delivery status permanently "sent"; credential rotation requiring a fork; and — new with v4.0.0 — dependency resolution failures on PHP 8.2+ that surface only at install time. Each is a production incident class, and none is observable through the package's surface.

Ramp-up. Technically shallow — any engineer can learn the Skebby API in an afternoon. v4.0.0 slightly improves discoverability by linking to the vendor's REST docs, which is genuinely useful. But the bundle itself still offers no README depth and no cited tests, so engineers will read source to answer basic questions. That is unbounded time for a bounded problem.

Recommendation. Do not adopt. v4.0.0 is a real but non-qualifying release: it confirms the Symfony-only constraint, bumps a major version without a changelog, and adds nothing toward Laravel compatibility, delivery receipts, or observability. The 0.005 score and 11.67 opportunity rating remain consistent with the repository. Build a thin in-house SkebbySmsSender behind an SmsSender interface — faster to ship, cheaper to own, fully observable, and vendor-swappable. The evaluation reopens only if (a) we standardize on Symfony 5.4/6.0, or (b) a future release ships a Laravel service provider with tested delivery-receipt support. Neither condition holds today.