Nova Boolean Datetime Field Laravel Package

Product Decisions This Supports

• Scheduled publishing / content lifecycles — the "toggle + timestamp" pattern maps directly to decisions like publish now vs. schedule, expire content vs. never expire, or enable promotion vs. auto-end date. Each of these is a real product decision that shows up in roadmaps for CMS, marketing, and commerce features.
• Optional or nullable temporal attributes — features such as "trial ends at" (or never), "event starts at" (TBD), and "feature flag active until" need a UX that cleanly expresses on/off plus a moment in time. This package encodes that decision in a single field rather than two loosely coupled columns, reducing the chance of invalid states (a datetime set while the boolean is false).
• Build vs. buy for admin tooling — a Nova field is a small, well-bounded artifact. Adopting this package is a "buy" of roughly 100–300 lines of custom field logic at zero cost, versus an internal build of a custom field component plus tests and ongoing Nova-version compatibility work.
• Accelerating internal admin/back-office delivery — for products where the admin panel is an operational tool rather than a customer-facing surface, this shortens time-to-ship for ops-facing features (managing promotions, content schedules, subscription grace periods).
• Use cases to validate against roadmap — content scheduling, promo/campaign windows, subscription and trial expiry, time-boxed entitlements, incident/maintenance windows, and any "active from / active until" construct.

When to Consider This Package

Consider adopting when:

• The product already runs Laravel Nova and the team is comfortable with custom fields as a normal extension mechanism.
• You have an immediate, well-scoped need for a boolean-gated datetime field (one or two resources) and want to avoid writing a Nova field from scratch.
• The field's behavior matches your data model — i.e., you genuinely want a nullable timestamp whose presence is signaled by a separate boolean, not a single nullable column.
• You can pin and vendor/fork the package. At MIT with a small surface area, the cost of forking is low, which materially de-risks the low community signal (21 stars, 0 dependents, single maintainer).
• You have someone who can own Nova majors — the real lifecycle risk is Nova version churn (v4 → v5), not the package's own code.

Look elsewhere (or build in-house) when:

• The product is not on Nova, or is planning to move off it — the value is entirely Nova-shaped.
• You need richer temporal semantics: recurrence, timezone-heavy scheduling, date ranges, duration/interval pickers, or calendar UI. A dedicated datetime/scheduling package or a first-party component is a better fit.
• You require vendor support, SLAs, or security review sign-off on a dependency with a single maintainer and negligible adoption.
• Your policy mandates actively maintained dependencies with observable usage; 0 dependents and low stars means near-zero peer validation and a thin bug-report signal.
• The "boolean + datetime" pair is really a derived state in your domain — in that case, model a single nullable timestamp and derive the boolean, avoiding a class of inconsistent-record bugs.

Adoption gate I would apply: confirm Nova version compatibility and PHP version support against your stack, check commit recency and open-issue posture, and timebox a one-resource spike. If the spike exceeds the cost of a small in-house field, build it — the artifact is small enough that ownership is cheap and removes the dependency entirely.

How to Pitch It (Stakeholders)

For executives (30-second version): This is a small, free (MIT-licensed) add-on for our Laravel admin panel that lets operators set a date and time with an on/off switch in one control — the pattern behind "publish now or schedule," "this promo ends on…," and "trial expires or never." It removes a recurring piece of custom admin work and reduces operator error from mismatched toggle-and-date fields. Cost is zero, the code footprint is tiny, and because it is MIT and easily forked, the downside is bounded: if it goes stale, we take a day to internalize it. The real risk isn't the package, it's Nova version upgrades — which we already own.

For engineering:

• What it is: a Nova custom field rendering a boolean toggle paired with a datetime input; the timestamp is only meaningful when the toggle is on.
• Why it's a good fit: it collapses a two-field pattern into a single validated control, eliminating the inconsistent-state class of bugs (date set, flag off).
• Honest risk read: 21 stars, 0 dependents, single maintainer — treat it as source you adopt, not a vendor you depend on. Pin the version, review the field class (it's small), and be prepared to vendor or fork.
• What we'd do: a timeboxed spike on one resource; verify Nova/PHP compatibility first; if the spike drags, write the field ourselves — the maintenance delta is small and it removes an external dependency from our upgrade path.
• Recommendation: adopt for internal/admin-only surfaces where the pattern recurs; do not introduce it on customer-facing or otherwise high-blast-radius flows without a code review.