Laravel Iranian Sms Laravel Package

Product Decisions This Supports

• Market-entry scoping for Iran-facing products. If Iran is on the roadmap, SMS is a hard dependency for OTP login, transaction confirmations, and delivery updates. This package is a cheap way to enumerate the operator landscape (Kavenegar, MelliPayamak, Farapayamak, SMS.ir, etc.) and pressure-test whether a single abstraction layer over them is viable before committing engineering time.
• Build vs. buy vs. fork. MIT license and a driver-per-operator structure mean the marginal cost of "buying" is near zero — but the real decision it informs is whether to fork and own the driver layer rather than depend on it. That is a resourcing decision, not a licensing one.
• Roadmap sequencing for notifications. The package covers transactional/message-send flows, not campaign management, delivery analytics, or inbound handling. It helps you decide whether SMS is a launch-blocking primitive (OTP) or a later-stage channel (marketing broadcasts), and scope accordingly.
• Vendor abstraction strategy. Whether to standardize on one Iranian operator with a direct SDK or keep two to three behind an interface for failover and pricing leverage. The package's shape argues for the abstraction; its maintenance state argues for building that abstraction in-house.
• Prioritization signal on tech debt. If your stack is Laravel 9/10/11, adopting this creates an immediate upgrade obligation. The opportunity cost belongs in the roadmap conversation, not buried in a ticket.

When to Consider This Package

Consider it when:

• You are on Laravel 5.x and have no near-term framework upgrade — the supported-version gap is the single biggest adoption constraint, and it is not a small one (Laravel 5.x has been end-of-life for years).
• You need multiple Iranian operators behind one interface and want a working reference for driver contracts, config shape, and payload differences rather than reading six sets of Persian-language API docs.
• You are running a time-boxed spike (1–3 days) to validate SMS delivery in the Iranian market and want to skip the boilerplate.
• You are comfortable vendoring or forking the code and treating it as a starting point you own.

Look elsewhere when:

• You are on Laravel 8+. Operator APIs have moved on since the March 2021 release, and there is no Laravel 9/10/11 support, no upgrade path, and no maintainer activity to produce one.
• You need production SLA, security disclosure, or support. 25 stars, zero dependents, and a dormant repo since 2021 mean no community validation and no channel to report a leaked-credential or injection bug. Enterprise procurement and security review will flag this as unmaintained third-party code.
• You need anything beyond send: inbound message handling, delivery receipts, cost reporting, templated/pattern-based messaging (a common requirement with Iranian operators for OTP), or bulk campaign tooling.
• You need credential hygiene guarantees. SMS API keys are high-value; verify the package reads them from env/config rather than committing them, and verify logging does not echo request payloads containing OTPs.
• A ~150–300 line in-house adapter over Laravel's HTTP client would cover your actual operator set. For most teams using one or two operators, that is cheaper over 24 months than owning a fork of a stale dependency.

Verdict: treat this as a reference implementation to read, not a dependency to install. The driver structure is the valuable asset; the package itself is not a durable one.

How to Pitch It (Stakeholders)

To executives: We identified a low-cost, MIT-licensed starting point for Iranian SMS integration that covers most local operators. It gives us a fast read on the market's operator landscape and a working prototype path for OTP and transactional messaging. The catch is maintenance: the project has been dormant since March 2021 and only targets Laravel 5.x, so it is not something we can safely depend on in production. Recommendation: fund a short spike to extract the integration patterns, then own a small in-house adapter — roughly days of work, not weeks, and it removes a single-maintainer supply-chain risk from a component that touches authentication.

To engineering: Use it as documentation. Clone it, read the driver contracts and config structure for the operators you care about, and port the pieces you need onto Laravel's HTTP client with your current framework version. Do not add it to composer.json. Validate two things explicitly before you trust any pattern from it: that API credentials come from environment configuration, and that OTP codes are never written to logs. Budget a short spike, produce an internal adapter, and add contract tests against each operator's sandbox.

Risk summary to attach: single maintainer · no releases in ~4 years · zero dependent packages · no security disclosure process · hard framework version lock. All mitigable by forking; none mitigable by waiting.