Should I vibe code
Offer booking pages with availability rules, confirmations, and rescheduling
A stale calendar token doesn’t throw an error. It just keeps offering slots you’re already busy in.
?
Their verdict, the Individual price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
The slot arithmetic is where everyone starts and it is the part already solved — Cal.com is sitting on GitHub with the time-zone handling, the buffers and the recurrence rules argued over by people who got them wrong first. What YouCanBookMe sells on top is duller and much harder to replace: a two-way connection to your real calendar that keeps working. Your version reads free/busy through an OAuth token that will, at some point, stop refreshing, and the failure is not an error page. It is a booking page cheerfully offering Tuesday at 10 while your calendar fills up behind it, and the first person to notice is a stranger who cleared their morning. Attach the intake form to that — name, email, phone, “what would you like to discuss” — and you are running a public personal-data collection point on infrastructure you configured on a Sunday.
What actually breaks
not "if". the specific failures.
- Token refresh, silently. The sync stops, the page keeps taking bookings, and nothing pages you because nothing errored
- Daylight saving. The last Sunday in March moves 9am for half the planet, and the person who booked it is the one who discovers this
- Double-booking under concurrency — two people accepting the same slot in the same second is a database transaction question, not a calendar question
- Reminder deliverability, where a reminder in a spam folder and no reminder at all produce identical outcomes
- Cancel and reschedule, which is three flows deep once you include rescheduling something already rescheduled, and is where every homemade booker gets thin
- The intake form: an unauthenticated endpoint that strangers post personal data to and bots post nonsense to, which creates calendar events and sends email
- Calendar API deprecations and OAuth consent-screen reviews, which are somebody’s ongoing job at every scheduling company on earth
Is that you?
the verdict is a default, not a law
- It is your own calendar, your own link, and you would notice within a day if the sync stopped
- You read free/busy rather than event details, and store nothing you did not explicitly ask for
- Confirmations go out through a real transactional email provider on an authenticated domain
- You are scheduling on behalf of other people — round-robin across a team is a distributed consistency problem with feelings attached
- A missed appointment costs the other person money or a day of annual leave
- The form collects a phone number, a company and a free-text box purely because the form builder made it one click
- There is no alert anywhere that fires when the calendar connection dies
If you build it anyway
the checklist, then the prompt that enforces it
- Treat the calendar OAuth token as a credential: encrypted at rest, refreshed on a schedule, monitored. Alert when a refresh fails, not when a booking goes wrong.
- Write the booking into your own store inside a transaction with a uniqueness constraint on the slot, then create the calendar event. Do not let a third-party API be your lock.
- Store instants in UTC with the IANA zone name alongside — never a fixed offset — and test a booking across a DST boundary in both hemispheres.
- Ask for the minimum. Every extra field is personal data you now have to secure, justify and delete.
- Ship the retention rule and the deletion job in the same commit as the bookings table.
- Rate-limit the booking endpoint and add a bot check, because it is a public endpoint that writes to your calendar and sends mail on your behalf.
- Reconcile nightly: compare the slots you are advertising against the real calendar and alert on drift rather than waiting for a human to spot it.
I am building a public booking page backed by my real calendar. Assume the sync will stop working silently, and build the detection before the features.
1. Treat the calendar OAuth token as a credential: encrypted at rest,
refreshed on a schedule, monitored. Alert when a refresh fails, not when a
booking goes wrong. This is the entire failure mode of this project.
2. Add a nightly reconciliation that compares the slots I am advertising
against the real calendar and alerts on drift. Write it before the UI.
3. Store instants in UTC with the IANA zone name alongside — never a fixed
offset — and render in the booker’s zone. Include a test that books across
a DST boundary in two hemispheres.
4. Write the booking into my own database inside a transaction with a
uniqueness constraint on the slot, then create the calendar event. Do not
let a third-party API be the lock; show me two simultaneous bookings.
5. Ask for the minimum on the form: name and email. Every extra field is
personal data I must secure, justify and delete, and I will not notice that
at the moment the form builder makes it one click.
6. Publish a retention rule and ship the deletion job in the same commit as
the bookings table.
7. Rate-limit the booking endpoint and add a bot check. It is an
unauthenticated endpoint that creates calendar events and sends email.
8. Confirmations and reminders go through a transactional email provider on an
authenticated domain, with a bounce webhook. A reminder in a spam folder is
the same as no reminder.
9. Build cancel and reschedule as first-class flows with signed links, and
handle rescheduling something that was already rescheduled.
10. Read only free/busy from the calendar — not titles, not attendees — and
say so on the booking page.
11. Out of scope unless I ask: team round-robin, payments, SMS and multiple
calendar providers. Then tell me what self-hosted Cal.com would give me.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
Anyone other than you depends on the page being right. Nine dollars a month buys calendar integrations that somebody else keeps working through API deprecations, a reminder pipeline with real deliverability, and the reschedule flow you were going to skip. If self-hosting appeals more than subscribing, run Cal.com — it is the same argument with a different bill, and you still are not writing the time-zone code yourself.
$9/mo is cheaper than your weekend.
Bookings live in your database with the attendee details, the slot and the calendar event ID, exportable as CSV and ICS. Revoke the OAuth grant, export, and point the old link at a hosted booker with a redirect — the events already on your calendar are unaffected, because they are on your calendar and not inside your app. Keep the public URL under a path you control rather than a subdomain the tool owns, so migrating does not invalidate every link in your email signature.
Mature open-source scheduling platform with calendar integrations and booking workflows.
Questions
How does this differ from the Calendly entry?
Calendly is where the argument about publishing your availability to the internet lives. YouCanBookMe earns its own page for the two-way calendar sync: the product is a live connection to a calendar you already use, so the interesting failure is not the booking form, it is the token that quietly stops refreshing while the page keeps saying yes.
Surely time zones are a solved problem?
They are solved in libraries and unsolved in codebases. The bugs that survive are the ones where a fixed UTC offset was stored instead of a zone name, or where recurring availability was expanded once and cached, so a DST change shifts every future slot by an hour and nothing complains until somebody joins a call at the wrong time.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
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.
Team booking means colleagues’ calendars depend on your cron job being awake.
Natural-language event parsing is delightful. Recurrence rules are a war crime.
TidyCal is twenty-nine dollars once. Yours is a weekend now and a calendar-API migration every spring.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice