Laravel Chronos Laravel Package

Product Decisions This Supports

Feature scoping — the "scheduling core." Chronos is a domain engine, not a UI kit: recurring availabilities (days, daily windows, validity ranges), appointments with lifecycle states (booked / cancelled / completed), impediments that block time (leave, training), automatic next-available-slot search, and 17 built-in business validation rules (minimum duration, buffer between appointments, no double-booking). This tells you precisely which parts of a booking feature you would otherwise have to build and maintain yourself: conflict detection, recurrence expansion, blocked-period impact analysis, and status transition guards.

Build vs. buy vs. borrow. Given 0 stars, 0 dependents, and docs-only maturity, frame this as borrow-first, buy-never, build-last. Its highest near-term value is as a reference design and spec document: the README already enumerates the business rules and edge cases (infinite-loop protection on slot search, partial vs. full impediment blocking, scoped services via ->for($owner)). That enumeration alone de-risks estimation and saves discovery time even if you never install it.

Roadmap sequencing. Adopt or emulate the core now; explicitly defer or exclude the adjacent roadmap items it does not cover — payments/deposits, reminders and notifications, calendar sync (iCal/Google/Outlook), waitlists, cancellation policies, resource capacity > 1 (room + practitioner simultaneously), and recurrence exceptions. Those are separate epics and should not be assumed solved by this package.

Data model and architecture decisions it forces early. The ->for($doctor) scoping pattern bakes multi-actor/multi-tenant ownership into the domain from day one — a good default if you'll ever have more than one practitioner, location, or tenant. The DateTimeZuluVO (UTC/"Zulu") and typed collections (SlotVOCollection, BlockedPeriodCollection) push you to decide time-zone and DST policy before you write the first booking screen. That decision is expensive to reverse; this package makes it a conversation you have in week one.

Use cases worth mapping to your pipeline. Medical/dental practices, salons and spas, consulting and coaching, tutoring, equipment or room reservation, field-service windows — anywhere the unit of value is "is this person/resource free at this time, and can I prove it." If your product is not in that family, this is noise.

Estimating and staffing. The 17 explicit validation rules plus slot search plus impediment impact analysis represent several weeks of design and implementation for a small team. Use the README's rule list as a checklist to size the work whether you fork it, rebuild it, or buy a SaaS scheduling embed.

When to Consider This Package

Consider it when:

• You are on Laravel 10/11/12 with PHP 8.1+, and scheduling is a module of your product rather than the product itself.
• You need the availability → appointment → blocked-period triad and want a coherent, interface-driven core (*ServiceInterface contracts) you can bind and swap.
• You have a single-domain owner model (practitioner, clinic, location) and want ownership-scoped queries out of the box.
• Your team reads French comfortably, or you can absorb a short translation cost for docs.
• You are willing to vendor or fork and own the code — i.e., you treat it as a starting point under MIT, not as a maintained dependency.
• You want to validate a scheduling feature cheaply before committing headcount to it.

Look elsewhere (or build) when:

• Production risk tolerance is low. Zero stars, zero dependents, one maintainer, no visible release history or CI signal, and docs-only maturity read as a high bus-factor, no-support, no-security-response profile. Do not put this on a revenue-critical path without a fork-and-own decision and a named internal owner.
• You need concurrency guarantees. Double-booking prevention must ultimately be enforced at the database level (unique constraints, transactions, row locking). The README describes guards, not a locking strategy — verify before trusting it under load.
• Time zones and DST are user-specific. A UTC-only value object simplifies the model but does not solve per-user local time, DST transitions, or display-time conversion.
• You need calendar interoperability, payments, reminders, waitlists, recurring-exception handling (RRULE), or multi-resource capacity. None of that is in scope here; you'd be buying a core and building the rest anyway.
• You need vendor support, SLAs, or a broad hiring pool of people who've used it. None exist.
• You are not on Laravel, or you'd rather embed a mature scheduling SaaS (Cal.com, Calendly, Cronofy) and keep your domain thin.

Recommended gate: a timeboxed 2–3 day technical spike — read the source, confirm tests exist and pass, review migrations and indexes, stress the slot-search concurrency story, and test a DST boundary. Continue only if the spike passes and you accept ownership of the code.

How to Pitch It (Stakeholders)

To executives: This is a low-cost probe into a scheduling feature, not a platform commitment. It gives us a pre-shaped domain model and an explicit list of the business rules a booking product needs — the parts that are easy to underestimate and expensive to get wrong. The risk is that it is an unproven, single-maintainer open-source library with no adoption, so we cap our exposure: a short evaluation, no production dependency until we've reviewed the code and accepted ownership. Worst case we spend a few days and come away with a validated spec and a better estimate. Best case we skip weeks of core development. Either way we make a deliberate make-versus-buy call instead of defaulting to building.

To engineering: Treat it as a reference architecture and a potential fork, not a dependency. What's genuinely useful: interface-first service contracts, typed records/value objects, typed collections, ownership scoping built into the service layer, a documented set of 17 validation rules, and explicit protection against infinite loops in slot search. What's missing or unproven: concurrency and locking guarantees for double-booking, per-user time zones and DST, recurrence exceptions, calendar sync, notifications, payments, and capacity beyond a single owner. Ask: does it have tests, are migrations indexed sanely, how does it behave across a DST change, and who owns the fork if we adopt it? MIT license means forking is cheap; zero stars means the fork is mandatory, not optional.