Sms Counter Php Laravel Package

Product Decisions This Supports

• SMS cost forecasting and budget guardrails. Every SMS is billed per segment, not per message. This library lets the product surface an accurate segment count (and thus estimated cost) before send, so pricing pages, campaign previews, and internal cost dashboards reflect reality rather than a naive strlen() / 160.
• Preventing silent message splits. A single emoji or a curly quote flips a message from GSM-7 (160 chars/segment) to UCS-2 (70 chars/segment) — instantly tripling segment count and cost. This package makes that encoding switch visible to product and support teams instead of surfacing as a surprise on the invoice.
• Character-counter UX decisions. Decides whether the compose UI shows "142 characters remaining" (GSM) or "38 remaining" (Unicode), and when to warn "this will send as 2 messages." That is a retention-relevant UX detail for OTP, alerts, and marketing flows.
• Build vs. buy on a commodity utility. This is ~a few hundred lines of well-understood spec logic (GSM 03.38 tables, extension characters, UCS-2 counting, 153/67-char multipart limits with UDH overhead). The decision is not "should we build an SMS platform," it's "do we spend an afternoon writing and testing this, or take a dependency?" For most Laravel teams the honest answer trends toward a thin in-house helper — this package is the shortcut, not a strategic bet.
• Roadmap sequencing for messaging channels. Knowing SMS is expensive-per-message and segment-sensitive informs whether SMS launches as OTP-only, notification-only, or marketing-capable — and whether the roadmap needs a "smart fallback to push/email when segment count exceeds N" feature.
• Vendor/gateway selection input. Gateways differ in whether they bill on submitted segments vs. delivered segments. A reliable local counter gives you the reference number to reconcile against carrier invoices.

When to Consider This Package

Adopt when:

• You're on PHP/Laravel and sending SMS through any gateway (Twilio, Vonage, local aggregators) and want gateway-agnostic counting rather than relying on a provider SDK's helper.
• You need a pre-send check inside a queue job or form validation — the "framework-agnostic simple PHP API" fits Laravel service classes and form requests cleanly.
• Your message volume or per-message cost is high enough that a 2x segment mistake is visible on the bill.
• You have appetite to vendor/fork and pin the code, add your own test suite around it, and treat it as internal.

Look elsewhere — or build — when:

• Maintenance risk is disqualifying. Last release 2019-06-06, 49 stars, unknown repo provenance, no visible PHP 8.x validation. For a dependency in the send path of a revenue feature, the PM should assume you own it after adoption. Verify PHP 8.2/8.3 compatibility and GSM extension-character handling before committing.
• You need more than counting: Unicode normalization, emoji/ZWJ handling, MMS, templating, scheduling, delivery receipts, opt-out compliance, or routing. This library does exactly one thing — it is not an SMS platform and shouldn't be pitched as one.
• You're on a managed messaging platform (e.g., a provider that already returns num_segments on the API response). Double-counting locally adds no information.
• Regulatory or compliance requirements demand a maintained, auditable, ideally vendor-supported component.

Decision rule: treat this as a reference implementation to copy or fork, not a long-lived dependency — unless a spike proves PHP 8 compatibility and you're comfortable owning the spec tables.

How to Pitch It (Stakeholders)

To executives: "SMS is billed per 160-character chunk, and a single emoji can cut that to 70 — so the same message can cost 2–3x what we budgeted. This small MIT-licensed library tells us the real segment count before we send, which means accurate cost estimates, fewer surprise invoices, and no accidental message splits in customer-facing comms. It's roughly a few hundred lines of well-defined spec logic — negligible cost, low integration risk — but it hasn't been updated since 2019, so I'm recommending we vendor it and add our own tests rather than treat it as a supported third-party dependency. Expected effort: under a day. Expected payoff: predictable SMS spend and a cleaner composer UX."

To engineering: "Framework-agnostic PHP, single-purpose: detects GSM-7 vs UCS-2, counts characters and segments including multipart UDH overhead. No Laravel coupling — wraps cleanly in a service class or validation rule. Caveats: stale (2019), small community (49 stars), unverified on modern PHP; plan to fork/pin, add tests for extension characters and emoji, and keep the gateway SDK as the source of truth for the actual billed segment count so we can reconcile."