// the problem
Small and mid-size rental businesses in the Dominican Republic run on phone bookings and spreadsheets, with no real-time view of fleet availability, revenue, or utilization. The two failure modes that cost real money are double-bookings and missed maintenance windows — and both are the predictable result of a calendar that lives in someone's head.
// the build
A self-serve booking site backed by an operational dashboard, with the invariants enforced where they cannot be bypassed.
›Double-booking prevention in the data layer, not the UI: a pre-save hook runs a date-overlap query against every pending and active rental for that vehicle and rejects a conflicting write. The guarantee holds when two requests race, or when a booking is created outside the normal flow — a front-end availability check holds in neither case.
›Fleet maintenance as domain logic rather than a checklist: the last service date drives the next due date on a 90-day interval, and an overdue vehicle is a query instead of a thing someone has to remember.
›Role-based authorization at the API boundary — shared middleware validates the session and role claim before any handler runs, so admin-only fleet writes and dashboard aggregates reject non-admins regardless of what the client sends.
›Dashboard KPIs computed server-side with MongoDB aggregation pipelines — revenue, active rentals, most-rented vehicles, week- and month-over-month deltas arrive as one payload, so the client renders numbers instead of recomputing them.
// what shipped
A working prototype end to end: data modeling, REST API, auth and authorization middleware, the customer fleet and booking UI, vehicle management, and the aggregation endpoints behind the KPI dashboard — all verified against a live database, with Jest coverage over the booking rules. Never deployed to a paying tenant; it stands as a reference build for making availability and access-control guarantees structural rather than advisory.
