Product Decisions This Supports
- Moving an operational chore off the engineering roadmap: Weekly opening hours per venue/branch/store are exactly the kind of request that arrives as a recurring ticket ("update our holiday hours," "we open Sundays now"). This field hands that upkeep to non-technical editors inside Nova, with day-level toggles, multiple time ranges per day, and closed-day handling. Frame the spend as internal tooling investment — it removes a class of low-value tickets and returns engineering capacity to the product backlog.
- A build-vs-buy call on a small but fiddly UI: A day-by-day time-row editor with validation, split shifts, and closed-day states is hand-work that looks trivial and isn't. Here the buy side costs an afternoon:
composer require, publish assets, wire the field into a resource, smoke test. That is a defensible "buy" as long as the requirement stops at capture.
- Data-model commitment with cheap optionality: Hours persist as per-weekday structured JSON on the model. That shape is the substrate for later features — store locator "Open now / Opens at 09:00" badges, per-location hours in a public API, holiday overrides — without a schema migration. The PM decision is to commit to that shape now, which is cheap, versus retrofitting it later, which is not.
- A deliberate scope boundary — capture, not evaluation: The field stores wall-clock times. It does not answer "is this location open right now," convert timezones, apply holiday exceptions, or reason about overnight spans. Adopting it is implicitly a decision that availability logic is our product logic and gets its own ticket. Surfacing that boundary at kickoff prevents a QA-stage surprise and a mis-scoped follow-up.
- An input into the admin-platform upgrade plan: v4.0.0 exists solely to add Laravel Nova 5 support, which makes it a lockstep dependency of the Nova 5 migration rather than an independent adoption. Nova's commercial license and upgrade cost dominate that decision; this field is a line item underneath it, and a useful forcing function to check whether the rest of the Nova add-on estate is 5.x-ready.
When to Consider This Package
Adopt when:
- You are already on Laravel Nova and want editors maintaining recurring weekly hours without custom UI work.
- Nova 5 is your target version (use v4.0.0). On Nova 4, pin to the 3.0.7 line — v4.0.0 is a hard major on the Nova axis, not a patch.
- The requirement is genuinely data capture — per-weekday ranges stored, edited, and displayed in admin — with no expectation of timezone math, holiday calendars, or slot generation from the component itself.
- You accept a single-maintainer community dependency with 38 stars and zero dependents. Blast radius is low (admin-only, one column, no public surface), but so is the support guarantee. Keep a documented rollback pin and the stored JSON shape on file so a fork or replacement is a day's work.
Look elsewhere or build in-house when:
- You are not on Nova — Filament, Livewire, Inertia, or Blade admin stacks gain nothing here.
- You need availability logic: open/closed evaluation, next-open-time, timezone conversion, holiday exceptions, overnight spans. Layer a library like
spatie/opening-hours on top; that is a separate build with its own estimate.
- You need vendor SLA, contract support, or audited/versioned multi-tenant hours. The data layer becomes yours regardless, so the field's UI value is marginal.
- Nova's license or upgrade cost is the real blocker. That decision dominates this one; do not let a small field justify or trigger a platform migration.
How to Pitch It (Stakeholders)
For executives (one paragraph): This is a small, low-cost admin component that lets non-technical staff keep location opening hours accurate without engineering involvement. Its newest release is a compatibility bump that unblocks our move to Nova 5 — the framework the back office runs on — so the real decision it forces is sequencing, not spend. Plan the Nova 5 upgrade and this field together with every other Nova add-on, and accept a short breaking-change window confined to the admin panel rather than anything customer-facing. Risk is contained: single-purpose, no public surface, no runtime services, an easy rollback to the previous major, and no vendor contract to unwind.
For engineering: Treat v4.0.0 as a lockstep dependency of the Nova 5 upgrade, not a standalone change — do not merge it into a branch where Nova is only partially upgraded. The release note says only "supports Nova 5," so verify rather than assume: confirm the composer.json constraints on laravel/nova, PHP, and Laravel, and diff a post-upgrade record against a pre-upgrade sample to prove the stored JSON shape is unchanged. Sequence: inventory resources using the field and capture samples → upgrade Nova 5 and confirm sibling Nova add-ons are 5.x-ready → move this package to ^4.0 with an explicit pin (no floating constraints) → nova:publish and clear caches → regression-pass create/edit/view covering closed days, multiple slots, split shifts, and overnight spans → promote with a documented 3.0.7 + Nova 4 rollback. One operational note: because the field is admin-only, monitoring will not catch a stale-asset or no-op-save break — add a post-deploy checklist item that round-trips an edit, plus a canary edit in production. File "open now," holiday exceptions, and timezone behavior as a separate ticket; this package stores hours, it does not answer questions about them.