Nova Date Range Laravel Package

Product Decisions This Supports

• Admin UX scoping — whether ops/admin users get a single-control start/end picker or two independent date fields; directly affects data-entry error rates and support tickets for scheduling-style records.
• Build vs. buy for internal tooling — vendor this MIT field, fork it, write our own Nova field (~1–3 dev days), or drop Nova form fields entirely in favor of a different admin stack.
• Data modeling — reinforces (or challenges) the decision to store ranges as two nullable start_at/end_at columns versus a single range/JSON column; surfaces questions about open-ended ranges, inclusive vs. exclusive end dates, and timezone/DST boundaries for "day" granularity.
• Roadmap inputs — campaign/promo windows, contract and subscription terms, booking/event periods, reporting period definitions, availability blackouts — any feature where an admin defines a span rather than an instant.
• Platform bets — implicitly a decision to keep investing in Laravel Nova (commercial, per-site license) as our admin layer; every Nova-specific package compounds that bet.

When to Consider This Package

Consider it when:

• We already run Laravel Nova and this is a form-field need (editing a record), not an index-screen filter need.
• The schema is already two nullable datetime columns and a migration is not worth it.
• Speed matters more than provenance: it's a small field class plus a JS datepicker asset, MIT-licensed, so forking and owning it is cheap.
• We're willing to pin the version and re-verify on every Nova major upgrade.

Look elsewhere when:

• We are not on Nova. Nova's license cost dominates any value here; evaluate Filament or a plain Blade + datepicker approach first.
• The need is filtering the index view — use Nova's built-in date filters, not a form field.
• We need real range semantics: timezone-aware intervals, recurrence, half-open intervals, availability/overlap logic. This is a UI widget, not a domain model — that logic is ours to build regardless.
• Risk tolerance is low: 26 stars, single maintainer, near-zero community. Nova 4/5 field API changes will likely break it and we become the maintainer.
• Strict accessibility, i18n, or design-system requirements apply — a small third-party field rarely clears those bars.

How to Pitch It (Stakeholders)

Executives: A free, narrowly scoped accelerator for our internal admin panel — worth it only because we already pay for Nova. It saves roughly a day of UI work, not a quarter. The real cost centers are the Nova license and our data model; this package is a rounding error and is trivially replaceable if it dies. Approve as a tactical convenience, not a platform commitment.

Engineering: MIT-licensed Nova custom field that wraps a JS date-range picker and maps it onto a start/end column pair. Small surface area — one field class plus published assets — so treat it as a vendored snippet rather than a dependency: read the JS, confirm null/clear behavior, timezone handling, and inclusive/exclusive end-date semantics before merging, and pin the version. Expect to patch it on Nova major upgrades. It does not solve interval logic, overlap detection, or filtering; budget separately for those if the feature needs them.