Alhazen Laravel Package

Product Decisions This Supports

• Build vs. buy for geographic reference data. This package appears to ship the two things teams most often rebuild badly: migration files that create location tables and a bundled "locations" dataset (countries/regions/cities). That is a direct build-vs-buy input — the alternative is owning an ISO-3166 dataset, keeping it current, and writing seed/import tooling in-house.
• Feature scoping for anything address- or territory-shaped. Country/region/city pickers, address capture at signup/checkout, shipping zones, tax jurisdictions, pricing by region, market/territory segmentation. If two or more roadmap items need the same reference tables, adopting one shared source beats three bespoke implementations.
• International expansion sequencing. A locations dataset is the cheapest way to unblock "launch in N new markets" scoping conversations before committing to localization, currency, or compliance work.
• Roadmap risk flag, not a roadmap commitment. At 0.1.1, with the only known change being fixes to loading migrations and loading the locations package, the honest read is that 0.1.0 was non-functional on install. Treat this as "viable enough to spike," not "approved dependency."
• Buy-vs-integrate. Distinguish reference data (static, low churn — a package is fine) from address validation, geocoding, and postal-code resolution (high churn, vendor-backed — a package is usually not fine). Decide these separately; they get conflated in scoping constantly.

When to Consider This Package

Adopt or spike when:

• You need static administrative divisions (country → region/state → city) as seeded tables, and "good enough and local" beats "authoritative and live."
• You want migrations included, so schema creation is one php artisan migrate rather than a hand-rolled data model — this release is specifically the fix that makes that promise true.
• You are pre-PMF or on a small team where a week of dataset wrangling is a week not spent on the core product.
• You can pin the exact version (0.1.1) and accept 0.x churn between upgrades.
• You have a fallback plan: your own table you can seed from a public dataset if the package stalls.

Look elsewhere when:

• You need postal code validation, address normalization, or geocoding — those require a maintained vendor (and money), not a static package.
• You need guaranteed data currency or a data-refresh SLA. Nothing in the release notes suggests a refresh pipeline exists.
• Your procurement requires vendor support, security review, or a maintainer responsiveness commitment. A 0.1.1 fix for "migrations don't load" tells you release QA is thin and there is no evidence yet of a maintainer SLA.
• You need sub-national data beyond the bundled set (municipalities, dial codes, timezones, currency mapping) — verify coverage before assuming it exists; the release notes say nothing about dataset scope.

How to Pitch It (Stakeholders)

To executives: A small, low-cost Laravel package that supplies the standard location tables (country/region/city) our address and market features need, so we don't spend engineering weeks sourcing, cleaning, and seeding that data ourselves. It is at version 0.1.1 — early-stage — and the release is a bug fix for install-time issues, meaning it just became usable. Recommendation: approve a short spike, not a production dependency decision. Cost of trying is hours; cost of building it ourselves is roughly a sprint, repeated whenever the data needs refreshing.

To engineering: 0.1.1 fixes loading of migration files and loading of the locations package — i.e., the package previously did not install cleanly. Pin 0.1.1 exactly, run migrate in a scratch environment, and confirm the seeded schema and dataset coverage against our actual requirements (which countries, which subdivision depth) before we wire it in. Treat the location tables as ours-and-replaceable: keep any application code behind our own model/repository boundary so we can swap the data source without touching feature code. Open questions we need answered before promotion past a spike: dataset provenance and licensing, refresh cadence, row counts per table, and maintainer responsiveness.