Dico Laravel Package

Product Decisions This Supports

• Reference-data strategy (build vs. buy vs. borrow). alis/dico is a dictionary/lookup-data manager for Laravel — the class of problem that shows up whenever you have controlled vocabularies: country and currency lists, industry codes, status catalogs, category taxonomies, reason codes, document types. The first real decision this supports is whether that data lives in config files, database tables, an admin UI, or a package. Dico points at "managed data, not hardcoded arrays," which is a legitimate product posture.
• Roadmap: letting non-engineers own taxonomies. If your roadmap includes operations or content teams curating lists (adding a payment method, a region, a compliance reason) without a deploy, a dictionary manager is a small but high-leverage enabler. It converts a recurring engineering chore into a self-serve workflow.
• Localization and multi-market readiness. Dictionary-style data is usually the first thing that needs translated labels per locale. If internationalization is on the 2–4 quarter horizon, evaluate whether this package's data model carries translations or whether it would be another table you have to bolt on.
• Scope containment for internal tooling. The best-fit use case is low-blast-radius: back-office admin panels, internal CRUD, configurable dropdowns. This is not a decision that belongs anywhere near revenue-critical pricing, eligibility, or entitlement logic without additional controls.
• Diligence flag, not a feature decision. Stars (3), dependents (0), and a package score of 0.075 are not a reason to reject the idea — but they are a hard stop on treating it as a platform dependency. The PM decision this really drives is "adopt, fork, or replicate the pattern in ~200 lines of our own code."

When to Consider This Package

Consider it when all of the following hold:

• Your need is genuinely dictionary-shaped: small, mostly-static records with a label, a stable key, maybe a parent/child grouping, maybe sort order and an active flag.
• You are on a supported Laravel version and want something that fits the framework's conventions rather than a standalone service.
• The dataset is internal or low-risk — a wrong entry is annoying, not expensive.
• You are willing to vendor or fork it. With 3 stars and 0 dependents, you are the maintainer in practice. MIT licensing makes that legal; it does not make it free.
• You treat it as a one-week spike, with a written exit criterion: does it remove more code than it adds?

Look elsewhere — or build the small table yourself — when:

• You need anything the package has not visibly proven: audit trails, approvals, versioning, per-tenant scoping, soft deletes, cache invalidation, or import/export.
• You need localized labels at scale, or the dictionary drives pricing, tax, or compliance logic where an unreviewed change has financial or legal consequences.
• You need a security posture, CVE response, or vendor support commitment. Single-maintainer projects with no dependents cannot provide these.
• The team is small and already fluent in Laravel; a dictionaries table, a model, and a cached accessor is often fewer lines than the integration work and carries no supply-chain risk.
• Your architecture is multi-language (TypeScript, Python, Go services around a Laravel admin). A PHP-tied dictionary becomes an API you have to write anyway — at which point the package is solving a smaller problem than you have.

Practical next step before any decision: read the migration and model files directly. Confirm the schema, whether soft deletes and timestamps exist, whether there is caching, and whether the last commit is within the current Laravel major version's lifecycle. Ten minutes of source reading substitutes for six months of stars.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a recurring pattern of hardcoded lists — countries, categories, statuses, reason codes — that require a developer and a release every time the business wants a change. A dictionary manager would let operations own those lists. The candidate package is MIT-licensed and free, but it is very early-stage: three GitHub stars, no downstream users, single maintainer. My recommendation is not to adopt it as infrastructure. Instead, we should spend a short, timeboxed spike to validate the pattern and then either fork it under our own name or implement a minimal equivalent — roughly a week of work — so we own the maintenance and the security review. Upside is low-cost and immediate; the risk we are avoiding is taking a silent dependency on unmaintained code.

To engineering (the ask): Timebox one week. Stand it up in a branch against a real dictionary we already hardcode, and answer three questions in writing: (1) Does the schema cover our actual needs — translations, ordering, hierarchy, active/inactive, audit? (2) Will it survive our next Laravel upgrade, or is it pinned to an older framework contract? (3) Does integration reduce our line count versus a plain Eloquent table plus a cached repository? If any answer is no, we replicate the approach. Regardless of outcome, wrap it — or our replacement — behind a single repository interface with a lookup() and options() method, so swapping implementations later costs a day, not a quarter. And record the decision with its rationale, because in eighteen months someone will find this package in composer.json and ask why.