Boolean Group Laravel Package

Product Decisions This Supports

• Admin UX for multi-flag records. The package provides a single Nova field that edits a group of booleans (e.g., notification preferences, feature toggles, permission switches) stored as one JSON column instead of N separate boolean columns. That directly supports a data-modeling decision: one JSON attribute vs. schema sprawl of many is_* columns.
• Build vs. buy vs. borrow. This is a "borrow" decision, not a strategic dependency. It is a thin presentation-layer field for a paid, closed-source admin framework (Nova), so the realistic alternatives are: (a) Nova's built-in BooleanGroup field, (b) an afternoon of internal work writing a custom field, (c) this package. Cost of replication is low; the decision is mostly about maintenance ownership, not capability.
• Feature scope and roadmap triage. Because the audience is limited to teams already licensed for Nova, a low-star / low-dependent package is a demand signal, not a product signal. Do not let it influence roadmap; treat adoption as an internal convenience at best.
• Internal-tooling spend. Useful only where the surface is a back-office admin panel. It has no bearing on customer-facing UX, API design, or performance budgets — so it should never appear in a customer-facing architecture review.
• Schema hygiene for settings-shaped data. If your product roadmap includes per-tenant or per-user settings matrices, this pattern (grouped booleans in one column) is a legitimate option worth evaluating — but evaluate the pattern, and implement it with first-party Nova fields where possible.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Laravel Nova (v4 or v5) and the editing surface is an internal admin panel, not a customer-facing one. Nova 5 is now explicitly supported as of v1.2.0, so a Nova 5 upgrade is no longer a blocker.
• You specifically need grouped boolean editing that Nova's built-in BooleanGroup does not give you — e.g., custom ordering, human-readable labels decoupled from the JSON keys, "select all / none" affordances, or conditional visibility between toggles.
• You are willing to vendor or fork the code and own it: pin the version in composer.json, read the ~few hundred lines of source, confirm it has tests, and confirm the PHP/Laravel/Nova version constraints match your stack.
• The blast radius of failure is a broken admin form, not a data-integrity or security incident — and you have a rollback path (the underlying JSON column is readable/writable without the field).
• You have done basic provenance diligence: license permits your use, single-maintainer risk is acceptable, and dependency review is satisfied with a low-star, low-dependent, two-release artifact.

Look elsewhere (or build in-house) when:

• Nova's built-in BooleanGroup already covers the requirement. That is the default answer and it costs zero maintenance.
• You are not a Nova shop. This has no value in a Filament/Inertia/Livewire stack; the equivalent is a handful of Toggle components.
• Individual toggles need identity — per-flag audit trails, per-flag authorization, per-flag timestamps, or querying/filtering on a single flag at scale. Then model each flag as a row, not a JSON key.
• You need support, SLAs, or a maintained dependency. Low stars, low dependents, and a two-release history mean effectively no community, no issue triage, and only one demonstrated major-version bump. The v1.2.0 Nova 5 PR is a good sign but not yet a track record across multiple Nova majors.
• Your org requires dependency provenance review for anything shipping into a regulated or enterprise environment.

How to Pitch It (Stakeholders)

One-liner for executives: A small, free UI add-on for our internal admin panel that lets an editor manage a set of on/off settings in one control instead of many checkboxes. It is optional, low-value, and we should treat it as disposable code we own rather than a vendor relationship.

For engineering: A Laravel Nova field that renders/edits grouped booleans (typically one JSON column). It duplicates a capability Nova already ships, so the decision is "use first-party vs. adopt-and-fork this." v1.2.0 adds Nova 5 support via a merged community PR, which confirms the field still works on current Nova but does not change the underlying risk profile. If we adopt: pin the version, read the source, add our own test around the column's read/write path, and keep a fallback because the package has one maintainer, negligible dependents, and no adoption signal.

Risk framing: Low technical risk (admin-only rendering), moderate maintenance risk (third-party field can break silently on future Nova majors — v1.2.0 addressed Nova 5 but there is no stated support policy beyond that), zero strategic risk (no lock-in — the data lives in a plain JSON column). Maximum downside is a day of engineering to replace it.

Recommendation: Default to Nova's built-in field. Sponsor this package only as a short-term internal convenience where it demonstrably saves UI work. The Nova 5 compatibility bump slightly improves the near-term picture and removes a hard blocker for Nova 5 shops, but with no dependents and no support commitment, budget the ~1 day to replace it in-house if it goes stale. Do not add it to any customer-facing roadmap or architecture standard.