Double bookings are not prevented by attention — they are prevented by the database

Without this

The calendar lives in a notebook or a shared file. One member of staff takes a booking on the phone while a colleague books the same week from another device, and nobody finds out until two customers stand at the counter on the same day. The office loses a booking and a customer at once, and an apology returns neither.

What the calendar guarantees

• A Postgres constraint refuses overlapping confirmed or active bookings on the same car — refused in the database, not in the browser
• An unconfirmed request never freezes a car, and a customer’s submitted request holds its window until a booking takes over
• The storefront picker and the checker on save read the same rule — so the calendar never offers a day the database will refuse
• Maintenance is an independent third axis: a car in the workshop disappears from public booking while the counter can still book it for after it returns
• Taking a car off the road never cancels a booking — it hands you the bookings that cross the window so you can ring the customers yourself
• Six statuses with governed transitions, including corrections for a mis-click and endings that are genuinely final
• Cancel and reinstate is allowed — and the database decides: if someone took those dates meanwhile, the reinstatement is refused
• A per-vehicle event history written by the database itself, with no update or delete permission for anyone — us included
• The maths: daily rate × days, plus add-ons (daily or flat) and later charges — with the refundable deposit kept out of the total
• A 365-day ceiling per booking — long-term rental still fits, while a typo cannot pull a car out of the fleet for years
• An alert when a return runs late — a nudge for a person, never a number that feeds an invoice