Nova Mega Filter Laravel Package

Product Decisions This Supports

Build vs. buy on the admin surface. The core trade is configure a community package against write and own custom Nova filter classes. Configuring this costs hours per resource; hand-rolling nested AND/OR filter UI costs days per resource and then sits on our maintenance ledger permanently. That trade favors adoption for admin-layer functionality with no external SLA — and favors building anywhere filtering logic becomes a differentiator.

Sizing internal-tooling investment. This is an admin-layer capability (Laravel Nova), not customer-facing product. It informs one recurring decision: how much to invest in ops/support/finance self-service data discovery. It should not be cited in pricing, growth, or customer-experience discussions.

Nova 5 upgrade sequencing. v1.1.0's only substantive change is Nova 5 support, delivered via a single first-time-contributor PR. That makes this package an upgrade gate, not a feature. If Nova 5 is on the roadmap, this clears a named blocker and belongs in that workstream so it isn't discovered late. If we're staying on Nova 4, v1.1.0 is functionally a no-op and should not drive any decision.

Prioritization evidence for internal-tooling requests. The justification is the volume of requests for filter combinations native Nova filters can't express — ad-hoc data pulls, exports, "can we slice orders by X and Y." Count those requests before adoption; that count is the business case, and re-checking it afterward is how we prove the package reduced requests rather than just relocating them.

Dependency portfolio hygiene. 85 stars, zero dependents, effectively single-maintainer, community-supported with no SLA. Adopting means budgeting tracking overhead: a line in the Nova-major upgrade checklist and a small fork/patch reserve each cycle. Blast radius is contained to the admin surface — if it fails, we revert rather than run an incident.

What it does not inform: pricing, customer experience, growth, or anything carrying an external SLA.

When to Consider This Package

Adopt when:

• We run Laravel Nova and internal users repeatedly request combined or multi-value filters that stock Nova filter classes don't comfortably express.
• A Nova 5 upgrade is planned or underway — v1.1.0 is the required floor; v1.0.5 will not run there.
• Resource count and filter-request volume are high enough that engineering hours saved clearly outweigh tracking overhead.
• We accept a community package that reaches into Nova internals, backed by a written rollback plan and a named internal owner.

Look elsewhere or defer when:

• We're not on Nova, or we're on Nova 4 with no near-term Nova 5 plan — no functional reason to take v1.1.0.
• We need vendor SLA, security-response commitments, or contractual support.
• Native Nova filters already cover the use cases — don't add dependency surface for parity.
• We've already heavily customized Nova filters; migration cost likely exceeds benefit.
• Our largest filtered tables are high-cardinality and unindexed; relationship filters can turn index pages into table scans.

Resolve before committing — these change the go/no-go:

1. What the product actually does. Marketing copy describes nested AND/OR groups with saved presets; developer notes describe a searchable multi-select replacement for the stock select filter. Those are different products. Confirm against source before scoping a roadmap story.
2. Whether v1.1.0 still supports Nova 4. The changelog says "Nova 5 Support" but not what was dropped. If the constraint became ^5.0 only, adoption is a silent platform bump that can raise our PHP/Laravel floor — the most expensive available mistake here, and it's caught by reading one composer.json.
3. Package identity. Repo is dcasia/nova-mega-filter; the package is listed as digital-creative/nova-mega-filter. Reconcile the Packagist name and latest tag before anyone writes an install ticket.

How to Pitch It (Stakeholders)

To executives — one line: A small, free, MIT-licensed add-on that lets our ops and support teams slice Nova admin data themselves, replacing repeated engineering requests with a config panel. Cost is hours of configuration per resource, not a project. Risk is contained to the admin surface, and the rollback is a version pin.

To engineering — the honest version: Community package, ~85 stars, zero dependents, single maintainer, no SLA. It hooks into Nova's filter internals, so a Nova major without a matching release can take down the entire admin UI — not just the panel. Mitigate with an exact version pin, staged Nova upgrades, a golden-query regression check in staging after every upgrade, and a named owner for upgrade tracking. Ramp-up is roughly half a day; the learning curve is Nova's filter API, not this package.

To finance/ops — what they get: Reusable saved filters for the queries they file tickets about, plus fewer round-trips to engineering for ad-hoc exports. Set the expectation that filter definitions are configuration, and configuration decays: presets referencing renamed columns fail quietly, so someone must own re-verification when resource columns change.

The framing to avoid: Don't sell this as a filtering platform or a data-access product. It's administrative convenience for internal tooling. The moment it's pitched as critical-path infrastructure, we've taken on an SLA we don't have.

The ask, concretely: Approval to pilot on one low-traffic, non-sensitive resource (Tickets or Users — not Orders, not anything finance reconciles against), with one engineer as owner, a rollback pin to v1.0.5, and a decision review after the pilot against the request-count baseline we recorded beforehand.