Myanmar Phone Number Php Laravel Package

Product Decisions This Supports

Feature-level

• Decides whether phone-first onboarding is viable in Myanmar. The package answers "can we validate a Myanmar mobile number at signup, in-process, without a third-party API?" That gates a whole acquisition funnel design (phone as primary identifier vs email fallback).
• SMS delivery strategy and cost model. Operator detection (MPT, ATOM/Telenor, Ooredoo, Mytel) allows per-operator routing and lets you price termination per carrier instead of assuming a blended rate. This is the single highest-value output of the package — validation alone is commodity.
• OTP retry and fallback logic. Sanitization (normalizing 09…, +959…, spaces, dashes, and Burmese/ASCII digit variants into one canonical form) reduces "number not recognized" failure states, which are usually a UX bug, not a user error.
• Data hygiene for CRM/support tooling. A canonical form means dedupe across signup, support tickets, delivery addresses and payment records actually works. Without it, the same customer exists 3–4 times.

Roadmap-level

• Market-entry sequencing. If the Myanmar roadmap item is real, this is a 1-day spike that de-risks the "phone number support" line item. If Myanmar is speculative, this package is not worth adopting yet — a spike on synthetic numbers is enough.
• Build vs buy for phone intelligence. The alternatives are (a) roll your own prefix tables, (b) adopt giggsey/libphonenumber-for-php (heavy, metadata-driven, multi-country), (c) pay an API (Twilio Lookup, Numverify), or (d) this package. This is a narrow, single-country, zero-dependency option — a legitimate "buy" only because the cost is near zero.
• Vendor/aggregator negotiation input. Knowing your user mix by operator tells you which SMS aggregator routes you actually need, and gives you leverage in pricing conversations. This is a decision this package's output directly feeds.

Operational use cases worth naming

• Rejecting obviously invalid numbers before they hit the SMS vendor (each failed send is billed by some vendors).
• Segmenting a user base by operator for carrier-billing experiments or promotional SMS.
• Flagging "valid format but implausible for this operator prefix" numbers for fraud review.
• Backfilling and cleaning an existing user table that was collected without validation.

When to Consider This Package

Adopt when all of these hold

• You have, or are about to have, a Myanmar user base — this is a single-country tool and has no value outside it.
• Your stack is PHP/Laravel and you want validation in-process rather than a network hop to a lookup API.
• You need operator name and network type, not just a boolean. If you only need "is this a plausible phone number," a simple length/prefix check you write yourself is sufficient and removes a dependency.
• You are comfortable treating the dependency as vendored code you own. With zero stars and zero dependents, you are the maintainer in practice: fork it, pin the version, and write your own test suite around real Myanmar numbers.
• You need offline / air-gapped / high-volume validation where per-lookup API cost or latency is unacceptable.

Look elsewhere when any of these hold

• Multi-country support is on the roadmap. Use giggsey/libphonenumber-for-php and accept the weight; retrofitting per-country packages one at a time becomes unmaintainable fast.
• Mobile number portability matters. Operator detection here is prefix-based. A ported number will be attributed to the wrong carrier — fine for analytics, dangerous if you use it to select an SMS route and guarantee delivery. If carrier-accurate routing is a hard requirement, you need an HLR/lookup service, not a static table.
• You need fixed-line, VoIP, or number-type classification beyond mobile. Out of scope for this package.
• You need a support contract, SLA, or security review sign-off. A single-maintainer, unstarred port with no dependents will not pass vendor risk review in a regulated environment.
• Metadata freshness is business-critical. Myanmar's numbering plan and operator ownership have changed repeatedly (Telenor Myanmar → ATOM, Ooredoo's ownership change, prefix reallocations). Static prefix tables decay. If nobody is watching upstream, your operator labels quietly rot — verify the table's vintage before trusting operator names in production.
• You need a first-class Laravel integration. Confirm it ships a service provider, config, and a Validator extension. If it's a plain PHP port, budget a thin wrapper (custom validation rule, sanitizer cast/mutator) as real work, not free.
• You expect community answers. No stars, no dependents means no Stack Overflow surface. Your team debugs alone.

Adoption gate: run it against a fixture set of ~200 real Myanmar numbers you collect yourself — including numbers from each operator, ported numbers, and malformed user input — before it touches a signup form.

How to Pitch It (Stakeholders)

For executives (2 lines): A small, free, no-dependency library that lets us validate and standardize Myanmar mobile numbers and identify the carrier at signup, so we stop paying for SMS to invalid numbers and can route messages to the cheapest carrier path. Single-country scope, near-zero cost, low strategic risk — but it's a small open-source project, so we'd fork and own it rather than depend on it blind.

For engineering: It's a PHP port of a known JS library, covering validation, sanitization, operator lookup and network type for Myanmar mobiles only. Value is the prefix table and canonicalization behaviour, not novel logic. Recommendation: vendor it, wrap it behind our own PhoneNumber service and a Laravel validation rule so we can swap in libphonenumber if we go multi-country, and hold it to our own test fixtures from day one. Do not call operator lookup for anything delivery-critical without acknowledging ported numbers break it.

For product/finance:

• Upside: fewer failed OTPs, lower SMS spend, clean canonical numbers for dedupe and segmentation, operator mix data to inform vendor negotiations.
• Cost: effectively zero licence cost; real cost is a small integration wrapper plus a fixture/test suite.
• Risk: unmaintained upstream and stale prefix data (operator naming in Myanmar has changed hands recently), and no carrier-portability awareness. Both are contained if we treat operator labels as analytics-grade, not routing-grade.
• Decision requested: approve a one-sprint spike to validate against real numbers and confirm the Myanmar onboarding assumption, before committing it to the roadmap.