Should I vibe code
Scheduling links for booking meetings without back-and-forth email
A booking link publishes your availability to the internet. Rate-limit it before you share it.
?
Their verdict, the Standard price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Slots, timezones and a calendar write is a good project. The public endpoint is the risk surface — unthrottled, it is a free way for anyone to fill your week.
What actually breaks
not "if". the specific failures.
- Double booking, because availability is computed, shown, and then written without anything holding the slot in between
- Timezones, where the booker's zone, your zone, and the DST rules on the date of the meeting are three separate problems
- Calendar sync, which is polling with an eventual-consistency window in which a slot is free on your page and busy in reality
- An unauthenticated public booking page, which is an open invitation to spam meetings and scraped email addresses
- Cancellation and rescheduling, which is most of the real usage and none of the demo
Two people open your booking page for the same 10:00 slot within a few seconds of each other. Both see it free, because both requests read availability before either wrote. Both get a confirmation email. At 10:00 on Thursday two strangers join the same call, and one of them has flown in for it. Nothing in your logs looks like an error — two successful bookings, exactly as the code was written, and the fix is a uniqueness constraint you did not know you needed.
Is that you?
the verdict is a default, not a law
- It is a personal booking page and a double booking costs you an apology
- Availability is a fixed weekly pattern rather than a live calendar read
- Everyone booking is in your timezone and you can say that honestly
- There is no database-level constraint preventing two bookings of one slot
- You store local times rather than UTC plus an IANA zone
- The page is public and has no rate limit or bot protection
- Clients or customers rely on it to reach you
If you build it anyway
the checklist, then the prompt that enforces it
- Put a unique constraint on the slot in the database and let the second insert fail. Application-level checks lose this race every time.
- Store UTC plus the IANA timezone name, never an offset and never a local time. Offsets change on dates in the future.
- Treat cached calendar availability as stale by default: re-verify against the provider inside the booking transaction before confirming.
- Rate limit the public page, require email confirmation before the event is created, and never expose other bookings.
- Build cancel and reschedule in the first version — they are most of the real traffic and the part people judge you on.
- Send calendar invitations as proper ICS with a stable UID so updates and cancellations replace rather than duplicate.
Before you build a scheduling link, apply these and push back if I ask you to break them. 1. Prevent double booking at the database level with a unique constraint on the slot, and handle the constraint violation as a normal outcome. Tell me that checking availability in application code before inserting always loses the race, and that two people booking within the same second is the common case, not the rare one. 2. Store every time as UTC plus the IANA timezone name of the person it belongs to. Never store offsets, never store naive local times. Write a test with a booking that crosses a DST transition in the booker's zone but not mine. 3. Treat any cached view of my calendar as stale. Re-check the provider inside the booking transaction before confirming, and fail the booking rather than confirming over a busy slot. 4. Rate limit the public booking page per IP and require the booker to confirm by email before the event is created. Explain that a public endpoint that writes to my calendar is an abuse surface. 5. Never leak other bookings — no names, no busy-slot details beyond unavailable. 6. Implement cancellation and rescheduling in the first version, with signed links that do not require an account. 7. Send ICS invitations with a stable UID and correct SEQUENCE so that updates and cancellations replace the original rather than creating duplicates. 8. Add buffer time and minimum notice as first-class settings, not afterthoughts. 9. Out of scope unless I ask: round-robin, team pooling, payments, workflows, reminders by SMS.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as clients book through it. $12 a month buys the double-booking constraint, the timezone handling and the reschedule flow — the three things that are invisible in a demo and are the entire product in practice.
$12/mo is cheaper than your weekend.
Because bookings live in the calendar provider as real events, the exit is mostly free — keep event UIDs and the booking metadata exportable so history survives. Keep the public URL on a domain you control, since that link ends up in email signatures and other people's bookmarks.
open-source Calendly — self-host and skip the OAuth pain
Questions
Why isn't checking availability before inserting good enough?
Because between the check and the insert, another request can do exactly the same thing. Both read 'free', both write. The window is milliseconds, which sounds safe until you notice that everyone clicks the same popular slot at the same time of day. A unique constraint makes the database arbitrate, which is the only place that can.
What's actually wrong with storing a UTC offset?
Offsets are not stable — a zone's offset depends on the date, and governments change the rules. If you store +02:00 for a meeting in eight months, and the DST rules shift, your meeting moves. Storing 'Europe/Berlin' plus UTC lets the conversion happen against current rules at display time.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
You will build twenty percent of Notion in a weekend and the other eighty for the rest of your life.
Team booking means colleagues’ calendars depend on your cron job being awake.
Natural-language event parsing is delightful. Recurrence rules are a war crime.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice