Nova Text Filter Laravel Package

Product Decisions This Supports

• Feature/UX investment in internal admin tooling. This package supports a small, contained improvement to the admin experience: a free-text input on Nova resource and lens index screens. Frame it as internal productivity tooling — cutting record-lookup time for support, operations, and admin staff — not as a customer-facing differentiator. The scope is deliberately narrow; it should never compete with customer-facing roadmap work for budget or attention.

• Build vs. buy (adopt-first for a narrow utility). A custom Nova text filter is cheap to write and easy to get subtly wrong: ungrouped orWhere clauses that leak past authorization scopes and soft deletes, unescaped LIKE wildcards, blank input degenerating into LIKE '%%' full-table scans, and driver-specific case sensitivity (MySQL collation vs. Postgres LIKE/ILIKE). Adopting a small package can be cheaper than an in-house build — provided you have explicitly accepted the version-compatibility and maintenance risk. This is the decision this assessment most directly supports.

• Roadmap sequencing and discovery. Use it as a low-cost probe before committing to larger search work: faceted filters, saved views, external search (Scout/Meilisearch), or database full-text. If admins get measurable value from a simple text filter, that's evidence to greenlight the bigger item. If they don't, you've spent a day and learned something — and avoided funding a search roadmap nobody asked for.

• Scoping internal vs. strategic. Keeps the effort correctly categorized. This is a presentation-layer UI filter, not core domain logic or infrastructure. It should not draw on strategic-platform budget or gate customer-facing commitments.

• Maintenance ownership and dependency governance. With 11 stars, 0 dependents, a single release in April 2023, and no SLA, this forces an explicit call: who owns the dependency, and what is the pre-agreed fallback — vendor it, fork it, or replace it with a ~30-line in-house base class if it stalls or breaks on a Nova upgrade? The decision record should name an internal owner and a fork-or-replace trigger before rollout, not after.

• Performance trade-off: where to deploy it. Leading-wildcard LIKE cannot use a B-tree index, so this suits modest admin tables, not large or high-traffic resources. The PM decision is which resources and lenses get the filter, plus a documented row-count threshold that triggers graduation to indexed or full-text search — keeping the same UI and routing the query to Scout/Meilisearch/Postgres FTS behind it.

When to Consider This Package

• You are already running Laravel Nova and need simple free-text filtering on resource or lens index views. If your admin surface isn't Nova, stop — the package provides no general Laravel search capability.

• The use case is an internal admin panel with low blast radius, where a small third-party dependency is acceptable and the team can review, pin, and — if necessary — own the code.

• You want to validate demand for better filtering quickly before investing in custom search, faceted filtering, saved views, or external search infrastructure.

• You can verify compatibility with your exact Nova/Laravel/PHP matrix and are willing to pin the version, commit the lockfile, revalidate on every Nova upgrade, and maintain a fork or fallback path.

• The searchable data sits on modest-sized tables where %term% queries are acceptable, and you have a plan to move to indexed or full-text search as volume grows.

• Look elsewhere if you need advanced or faceted search (multi-select, ranges, saved filter sets), high-volume performance guarantees, enterprise support or an SLA, a vendor with an active release cadence, or if you're not on Nova at all. Also look elsewhere if your team lacks the capacity to review and own a small dependency — in that case, write the ~30-line base class in-house and skip the package entirely.

How to Pitch It (Stakeholders)

For executives: This is a one-day, low-risk improvement to our internal admin tools. It gives support and operations staff a targeted search box on admin record lists, so they find accounts and records faster instead of scrolling or paging. Cost is negligible, the blast radius is confined to internal screens, and it doubles as a cheap experiment: if admins use it, we have evidence to justify a proper search investment; if they don't, we've spent almost nothing and avoided building search nobody wanted. It does not consume customer-facing roadmap capacity.

For engineering: It's a drop-in Nova filter base class — we extend it, implement apply(), register it on a resource's filters(). The package only gives us the UI component wired into Nova's filter panel; all the subtle correctness work stays in our own base class, which is the right split. We'll do that once: guard against blank input, escape %/_/\, group multi-column orWhere in a closure so it can't OR past authorization or soft-delete scopes, and settle case sensitivity against our actual database driver rather than development defaults. Concrete filters then become three lines each.

The risk we're accepting, stated plainly: the package is small — 11 stars, no dependents, one release in April 2023, community support only. That doesn't disqualify it, but it means "it installed fine" is not "it's compatible." So we pin the exact version, commit the lockfile, spike it on one low-risk resource, and put it on the Nova-upgrade checklist. We agree the fallback now — fork it or replace it with our own base class — and name an owner. We also decide up front which resources are permitted to use it, and at what row count we move the query behind Scout or Postgres full-text search while keeping the same UI.

Ask: approval to ship on one or two internal resources behind a feature flag, with usage instrumentation, and a review in 30 days to decide whether to expand, graduate to real search, or drop it.