Zap Laravel Package

Product Decisions This Supports

• Roadmap sequencing for a booking/scheduling capability. Zap provides the domain engine for availabilities, appointments, blocked time, and bookable-slot generation. It lets a PM scope an MVP around “define resource availability → expose bookable slots → create appointments” without budgeting a from-scratch recurrence engine.
• Build vs. buy for scheduling logic. Recurrence rules, overlap detection, buffers, and slot generation are deceptively expensive to build and test. Zap’s breadth—weekly odd/even, biweekly, monthly ordinal weekdays, quarterly/annual, dynamic intervals—supports a “buy/leverage OSS, build the product experience” decision rather than an in-house build.
• Resource-model expansion. The polymorphic HasSchedules trait supports doctors, rooms, employees, and shared spaces with one schema. A PM can sequence expansion across resource types without a new scheduling subsystem per vertical.
• Scope boundaries. Zap is a backend scheduling/query layer, not a booking product. It does not appear to cover booking UI, notifications, payments, cancellation policies, waitlists, calendar sync, or admin tooling. These must be explicitly staffed and roadmaped.
• Platform compatibility decision. The README states PHP ≥8.5 and Laravel ≥13.0—very restrictive, bleeding-edge requirements. This package should only enter the decision set for greenfield or explicitly upgraded applications. Verify composer.json constraints directly: release notes mention CI across PHP 8.2–8.5, which conflicts with the README’s ≥8.5 claim.
• Data-model and migration planning. UUID/ULID support requires pre-migration changes to models, config, and migrations. This is a low-cost decision if caught early and a costly retrofit if missed.
• Dependency and exit-risk management. MIT license, zero dependents, small maintainer footprint, and early maturity mean the PM should treat this as a tactical accelerator, not a strategic platform bet. Decide upfront whether the team will pin, wrap, or fork.
• AI-assisted delivery productivity. Laravel Boost skills may reduce onboarding time for AI coding agents, a modest but real delivery-velocity consideration.

When to Consider This Package

Consider Zap when:

• You are building on Laravel 13+ and PHP 8.5+, or are willing to verify and support that stack.
• The product needs resource-based availability and appointment booking: healthcare resources, meeting rooms, employee shifts, or shared-space reservations.
• You need recurring schedule patterns and slot generation but do not want to build that logic in-house.
• Your team can own the surrounding product surface: booking UX, notifications, timezone presentation, payments, and admin tools.
• You are comfortable with a young, single-maintainer OSS package and can pin versions, add integration tests, and maintain a fork/exit plan.
• You want a fast, time-boxed spike to validate scheduling assumptions before committing roadmap.

Look elsewhere when:

• Your application is on Laravel 12 or earlier / PHP 8.4 or earlier—the stated requirements are likely a hard blocker.
• You need a ready-made booking UI, admin calendar, or customer-facing scheduler; Zap is not that product.
• You require iCal, Google Calendar, or Outlook synchronization, enterprise support, SLA, or security certifications. The README mentions healthcare use cases, but there is no evidence of HIPAA/BAA readiness.
• Timezone/DST correctness across global users is a core requirement; the package documentation does not demonstrate this depth.
• You need concurrency-safe double-booking prevention under load as a guaranteed property; validate this explicitly rather than assuming it.
• You need cron-style background job scheduling; use Laravel’s native scheduler instead.
• You need a mature ecosystem with broad adoption; zero dependents and limited community signals are a poor fit for a low-risk, long-lived platform dependency.

How to Pitch It (Stakeholders)

For executives: Zap is an MIT-licensed Laravel scheduling engine that could accelerate a booking feature by removing the need to build recurring availability, overlap detection, and slot generation from scratch. The trade-off is maturity and platform lock-in: it targets very new PHP/Laravel versions, has a small maintainer base, and does not include the customer-facing booking experience. Recommendation: fund a short, time-boxed spike against our real use cases, not a full production commitment. Success should be measured by whether it handles our recurrence, buffer, and conflict scenarios without custom forks.

For engineering: The builder API is clean and the recurrence coverage is unusually broad, including odd/even weeks, ordinal weekdays, and dynamic intervals. It includes conflict detection, bookable-slot queries, metadata, custom validation rules, and multi-database CI signals. Key risks: restrictive PHP/Laravel requirements, documentation inconsistency around supported PHP versions, UUID migration friction, no timezone/calendar-sync story, and a single-maintainer bus factor. Mitigation: verify composer.json, wrap the package behind an internal scheduling interface, add integration tests for our scenarios, and keep a fork path open.

Ask: One to two sprint spike to validate fit on our target stack and top booking scenarios. Decision rule: proceed only if we are on Laravel 13/PHP 8.5, booking is a near-term roadmap priority, and the spike proves our recurrence and conflict cases with acceptable operational risk.