Cidadesbr Laravel Package

Product Decisions This Supports

• Brazil localization MVP: Enables a fast state/city dropdown for signup, onboarding, checkout, or profile forms without sourcing IBGE data or writing seeders. This is the strongest PM use case: validate demand and form completion before investing in a full address platform.
• Build vs. buy/borrow decision: The package is best treated as a reference implementation or seed-data source, not automatically as a production dependency. PM can frame the decision as “use package to accelerate discovery” versus “own a small, maintained location table.”
• Scope of address capture: Helps clarify whether the product needs only state/city fields or also CEP lookup, neighborhoods, coordinates, address validation, delivery zones, or geocoding. This package covers only states and municipalities, so it prevents overestimating what “address support” means.
• Search, filters, and segmentation: Supports basic location-based filters such as “cities in this state,” regional admin views, or Brazilian market segmentation. It does not support radius search, maps, geospatial queries, or delivery-zone logic.
• Data ownership and refresh planning: Because the last release is from 2015, PM should treat Brazilian municipality data as a product asset requiring an owner and refresh cadence. IBGE data changes over time through municipal creation, mergers, and name changes; stale data can affect address forms, reporting, and customer records.
• Roadmap sequencing: Good for a short compatibility spike or internal prototype; not a strategic dependency for a modern production platform without a fork-and-maintain plan.

When to Consider This Package

Consider it only when:

• The application is on a legacy Laravel/PHP version that is demonstrably compatible with a 2015 package, or the team is willing to fork and adapt it.
• The immediate need is a prototype, internal tool, demo, or MVP where stale state/city data is tolerable and address data will not drive billing, delivery, or compliance.
• The product needs only state/city reference data—not CEP lookup, street-level validation, neighborhoods, coordinates, or geocoding.
• The team accepts ownership: fork the package, audit migrations/seeders, update the IBGE dataset, and add tests for data integrity.
• Time-to-first-demo matters more than long-term dependency hygiene, and the package can be isolated behind an internal location service or lookup table.

Look elsewhere or build a small internal solution when:

• The product runs on modern Laravel/PHP and dependency compatibility is uncertain. The 2015 release date and low community signal (53 stars) are material adoption risks.
• The use case is production checkout, delivery, compliance, CRM, or billing, where stale or incomplete municipality data creates customer-facing or reporting errors.
• The roadmap requires CEP lookup, address validation, geocoding, neighborhoods, coordinates, delivery zones, or IBGE code-level reporting.
• The organization requires maintained dependencies, security updates, SLAs, or a clear data-refresh process.
• The product is multi-country or likely to expand beyond Brazil; a Brazil-only package becomes a localization dead end.

How to Pitch It (Stakeholders)

Executives: This package can accelerate Brazilian localization for basic state/city forms, but it is an abandoned 2015 dependency with stale IBGE data and low community support. Recommendation: do not make it a long-term production dependency without ownership. Use it as a reference or seed source, or budget a small internal effort to maintain a states/cities table. It reduces initial build time but does not eliminate the need to own location data quality.

Engineering: The package offers migrations, seeders, Eloquent models, and artisan commands, which lowers initial implementation effort for state/city relationships. However, the 2015 release likely conflicts with modern Laravel/PHP, and the data refresh path is unclear. If used, isolate it behind an internal lookup interface, audit migrations, fork if necessary, and add data-integrity tests plus a refresh process based on current IBGE data.

Product: Use this to unblock address forms, filters, and Brazilian market segmentation in an MVP, but do not position it as full address validation or geolocation. The PM decision is to time-box a compatibility spike and define whether the product needs only state/city fields or a broader address capability. If the latter, plan a maintained IBGE-backed dataset rather than relying on this package.