Select Or Custom Laravel Package

Product Decisions This Supports

• Build vs. buy on admin-only UI: This is a single Nova form field (~a few hundred lines of Blade/PHP) that solves the "pick from a list, or type your own" pattern. The decision it supports is not "should we adopt this package" so much as "should we spend engineering days building this ourselves for back-office screens" — the answer is almost always no. Adopt, and if it breaks, re-implement in under a day. Lock-in is near zero.
• Controlled vocabulary vs. long-tail capture: Most product taxonomies fail at launch because the options list is guessed. This field lets you ship a canonical list and an escape hatch, so you can capture real-world values (lead source, industry, job title, cancellation reason, "how did you hear about us," region) without blocking users or shipping a bloated enum.
• Data-driven taxonomy roadmap: Treat custom text entries as a discovery backlog. Instrument them, review monthly, and promote the frequent ones into the select options; retire the rest. This turns a form field into a cheap taxonomy-research loop instead of a guess.
• Deferring a real taxonomy/tagging system: If the roadmap eventually needs a managed categories table with admin CRUD, this field is a legitimate stopgap that buys you 1–2 quarters of learning at near-zero cost.

When to Consider This Package

Adopt when all of the following hold:

• You are already on Laravel Nova (hard prerequisite — it is a Nova field, worthless otherwise).
• The surface is internal/back-office, where an occasional messy free-text value is tolerable and someone will clean it up.
• The underlying column is a single string/varchar and normalization can live in a model mutator or Nova resolveUsing if you need it.
• You are comfortable forking and vendoring it (see risk below), because the maintenance signal here is weak: 0 stars, 0 dependents, last release Feb 2023, single maintainer, and the repo name (select-or-text) doesn't match the package name (select-or-custom).

Look elsewhere or build it yourself when:

• You're not on Nova — use Filament's Select with createOptionForm, or a plain datalist/combobox component.
• You need the custom value persisted separately, mapped to a canonical ID, deduplicated, or validated against a policy. This package saves the string; it does not model the relationship.
• You need current Nova/Laravel support guarantees. A 2023-dated Nova field may not survive Nova 4/5 or Laravel 11/12 without patching. Verify against your pinned versions before committing.
• The form is customer-facing, needs i18n, accessibility conformance, or an audit trail of who added a new value.
• You need a maintained dependency with a security-response path; 0 stars and 0 dependents means you are the only support line.

How to Pitch It (Stakeholders)

To executives: This is a small, free UI component for our internal admin tool. It lets an operator choose a standard value from a dropdown or type a new one when the list doesn't fit — which means we ship the feature this sprint instead of spending a week building and maintaining our own version. It also gives us real data on which "other" values customers actually use, so our category lists get better over time instead of being guesses. The risk is deliberately low: it's a thin layer on top of a column we already have, and if the package goes stale we can replace it in a day. Decision is reversible; cost is effectively zero.

To engineering: Drop-in Nova field, no schema migration beyond the string column you already planned. Two caveats to own: (1) it's a single-maintainer package with no recent releases — fork it into our repo and pin it, don't rely on upstream; (2) it stores raw free text, so add normalization/dedup in a mutator if downstream reporting depends on it. Verify compatibility against our Nova/Laravel versions as the first task, not the last.