Sms77 Laravel Package

Product Decisions This Supports

• Channel expansion in the notification stack. This package is a thin adapter that plugs sms77 (Seven) into Laravel's existing Notification system, so a PM can add SMS as a delivery channel next to mail, database, and push without redesigning notification logic or introducing a new messaging abstraction.
• Build vs. buy on a commodity integration. The integration surface is narrow (auth, send, status). Building in-house means owning an HTTP client, retry/error mapping, and config plumbing. Adopting this package converts that into a dependency decision measured in hours, not a sprint — a strong default when SMS is a supporting capability rather than a core product.
• DACH/EU market roadmap items. sms77 is a German provider, which makes this relevant for roadmaps that include German-language markets, EU data-residency expectations, or local sender-ID/regulatory handling. If the product is expanding into the DACH region, this is a cheap way to validate SMS-based flows.
• OTP, 2FA, and transactional alert features. The highest-value SMS use cases — login verification, order/delivery notifications, incident alerts — all ship as notification classes. This package lets those features be scoped as product work rather than infrastructure work.
• Provider-abstraction hygiene. Because it rides on Laravel's notification contracts, it keeps the option to swap providers later. That preserves a future "multi-provider SMS with failover" decision instead of foreclosing it.
• Low-cost experiments. With MIT licensing and a minimal footprint, the cost of a spike (e.g., "does SMS improve verification completion in our German cohort?") is low enough to justify as a timeboxed experiment rather than a business case.
• Framework-upgrade runway. v1.0.7 adds Laravel 13 compatibility (PHPUnit/Laravel version bumps in the test matrix), so this channel doesn't become a blocker when the platform upgrade lands. That reduces the risk that an SMS feature locks the team to an older Laravel major.

When to Consider This Package

Consider it when all of the following hold:

• The application is already on Laravel and already uses the Notification system for at least one other channel. Support now spans current Laravel releases through Laravel 13.
• sms77/Seven is the chosen (or strongly preferred) SMS provider — typically for German-market coverage, pricing, or an existing commercial relationship.
• SMS is a supporting capability (notifications, OTP, alerts), not the core product, and the team is comfortable pinning a small third-party dependency.
• You need something working this sprint, and the alternative is a custom client you'd have to own and maintain.

Look elsewhere when:

• You are not on Laravel, or not using its notification contracts — the package's entire value is the integration seam, and there is none.
• You are not on sms77/Seven. This is a single-provider adapter; it is not an SMS abstraction layer. If provider optionality matters, pick a multi-provider gateway or write your own interface around this one.
• Adoption signals matter to your risk model. Nine stars and zero dependents is a genuine bus-factor flag. The v1.0.7 release is maintenance (dependency bumps and style fixes) rather than evidence of a growing contributor base. Treat it as "small, unproven, possibly one-maintainer" — pin the version, wrap it behind your own notification/service boundary, and keep an exit path. The recent, on-time Laravel 13 support is a positive maintenance signal, but it is not the same as a healthy community.
• You need delivery analytics, failover, templating, or compliance tooling. This is a send-path adapter; richer messaging platforms cover routing, retries, and reporting that you would otherwise build yourself.
• Your procurement/security review requires established community support — in which case the review cost may exceed the integration savings.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed adapter that lets us send SMS through Laravel's existing notification system in a few hours instead of building and maintaining an SMS client ourselves. It supports near-term roadmap items we already want — verification codes, transactional alerts, and German-market messaging — at negligible cost and with no platform commitment. The latest release keeps it compatible with Laravel 13, so it won't block our framework upgrade path. The tradeoff is maturity: the project has a very small user base, so I recommend we adopt it deliberately, pin the version, and keep the integration isolated so we can replace it if needed. Net: low cost, reversible, and it unblocks features rather than infrastructure.

To engineering: Use it as the transport for an SMS notification channel, not as our SMS architecture. Keep provider-specific config and any sms77 calls behind our own notification class or service so that swapping providers later is a config change, not a refactor. Pin the dependency — v1.0.7 is a maintenance release (Laravel 13 support plus StyleCI fixes) with no API changes, so the upgrade is low-risk, but pinning still protects us from an unannounced breaking change in a one-maintainer project. Add a smoke test around the send path, and document the error cases we care about (invalid number, insufficient balance, rate limits) since we'll be relying on the package's mapping rather than our own. Do not extend it — if we need retries, failover, or delivery reporting, that's our layer to own.