Should I vibe code
Publish simple booking pages connected to one calendar and send confirmations
TidyCal is twenty-nine dollars once. Yours is a weekend now and a calendar-API migration every spring.
?
Their verdict, the Pro 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
Everything the Calendly entry says about slot races and timezone arithmetic applies here, so read that first. What TidyCal adds is the part that quietly turns a booking page into a ledger: paid bookings, recurring sessions and prepaid packs of five or ten. Sell someone a ten-pack and your database becomes the only record of how many sessions they have left, which is a balance, and balances are things people argue about in writing. Even without the money, the arithmetic is unkind — TidyCal's lifetime tier is twenty-nine dollars, once, and your version needs the Google Calendar API deprecation handled every year for as long as anybody still books through it. Build it to learn OAuth and DST. Do not build it to save the twenty-nine dollars.
What actually breaks
not "if". the specific failures.
- OAuth refresh tokens, which expire, get revoked when somebody changes a password, and fail quietly. Your page keeps publishing availability from a calendar you can no longer read
- The remaining-sessions count on a prepaid pack — a balance you owe somebody who has already paid, held in a mutable integer column with no ledger and no audit trail
- Reminder deliverability, because the whole value of a reminder is that it arrives, and confirmation mail from a domain with no SPF or DKIM lands in spam or nowhere
- Recurring bookings across a daylight-saving transition, where 'every Tuesday at 09:00' is two different UTC instants either side of the change and only one of them is what the client expects
- Cancellation windows and refunds, which is the point where a scheduling tool stops being a calendar and becomes a policy you have to enforce in code
- The public booking page as an open write endpoint. Unthrottled, it costs you a morning of deletions and a week that somebody else filled in
Is that you?
the verdict is a default, not a law
- It is your own booking page, one calendar, and no money changes hands
- A double booking costs you an apology and nothing more
- You are content handling cancellations by replying to the email
- Clients pay at the point of booking or buy session packs — that is a payments product with a calendar bolted on, and it belongs in a different band entirely
- A balance of remaining sessions lives anywhere other than an append-only ledger
- Reminders are what stop no-shows and you have not checked where your mail actually lands
- Your income depends on people being able to reach you through it
If you build it anyway
the checklist, then the prompt that enforces it
- Put a unique constraint on the slot and let the second insert fail. Checking availability in application code before writing loses the race every time, and popular slots are exactly where the race happens.
- Store UTC plus the IANA zone name for everything, and generate recurring instances against current rules at read time rather than materialising offsets months ahead.
- Treat calendar credentials as expiring by default: detect refresh failure, stop publishing availability immediately, and alert yourself loudly rather than serving stale free time.
- If sessions are prepaid, model them as an append-only ledger of credits and debits with a derived balance. Never decrement a counter — you will need to explain the arithmetic to somebody one day.
- Send transactional mail through a provider with SPF, DKIM and DMARC configured, and log delivery. A reminder that bounced is worse than one you never promised.
- Ship cancel and reschedule in v1 with signed, accountless links, and rate limit the booking page before you publish the URL anywhere.
I am building a personal booking page: one calendar, public slots, email confirmations. Assume it will end up carrying money, and order the work so that the parts I cannot fix later come first.
1. Prevent double booking with a unique database constraint on the slot and
handle the violation as an ordinary outcome. Tell me plainly that an
availability check followed by an insert always loses the race.
2. Store UTC plus the IANA timezone name, never an offset. For recurring
bookings, expand occurrences against current rules at read time and write a
test for a weekly series crossing a DST change in the booker's zone but not
in mine.
3. Treat the calendar connection as expiring. Detect refresh-token failure,
immediately stop serving availability, and alert me. Never fall back to a
cached free/busy view — publishing stale availability is the failure I most
want to avoid.
4. If I ask for paid bookings, session packs or subscriptions, push back
first. If we proceed: no card data touches my server, use a hosted
checkout, and model entitlements as an append-only ledger of credits and
debits with the balance derived. Never mutate a remaining-sessions integer.
5. Build refunds and cancellation-window enforcement alongside taking payment,
not after. A booking that took money and then failed to create the event
needs an explicit reconciliation path.
6. Confirmations and reminders go through a real transactional provider with
SPF, DKIM and DMARC, recording per-message delivery status.
7. Send ICS with a stable UID and correct SEQUENCE so reschedules replace
rather than duplicate.
8. Cancel and reschedule ship in v1 via signed accountless links, and neither
may leak any other booking.
9. Rate limit the public page per IP, require email confirmation before the
event is created, and expose nothing beyond 'unavailable' about a busy slot.
10. Out of scope unless I ask: round-robin, team pooling, SMS, questionnaires,
and any analytics on who viewed the page.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
Almost immediately, and the price is the argument. Twenty-nine dollars once, or twelve a month for Pro, against a weekend plus an OAuth migration every year and an email deliverability problem you will not enjoy. What you are buying is the boring third of the product: token refresh that notices when it breaks, reminders that arrive, and reschedule links that do not leak the rest of your week. Cal.diy is the free self-hosted route if you want the data on your own box.
$12/mo is cheaper than your weekend.
Bookings already live in Google or Microsoft as real events, so the calendar half of the migration is close to free — keep event UIDs and the booking metadata exportable and history survives. The parts that do not export themselves are the prepaid balances and the cancellation history, so keep those in a shape you could hand to an accountant. Keep the public URL on a domain you control, because it ends up in email signatures and other people's bookmarks long after you have stopped maintaining the code behind it.
The MIT-licensed community fork of Cal.com's scheduling platform, with the enterprise features stripped out.
Questions
It is a booking page. Why is a prepaid session pack such a big deal?
Because it stops being scheduling and becomes bookkeeping. Somebody paid for ten sessions and has used four; the number six exists only in your database. Every way that number can be wrong — a double-decrement on a retried request, a cancellation that did not credit back, a race between two tabs — is a conversation with a person who paid you money and remembers differently. An append-only ledger makes that conversation resolvable. A mutable counter does not.
How does the calendar connection break if I never touch it?
Refresh tokens expire, get revoked when the account owner changes their password or their admin rotates app permissions, and providers periodically retire scopes. The failure is silent by design — the API returns an auth error your background job swallows, and the booking page carries on serving the last availability it managed to read. People then book slots you are already in.
Is the lifetime price real?
Yes, and it is what makes this one hard to argue with. The Individual tier is twenty-nine dollars once, which is less than the API research alone will cost you in hours. That is not a reason to never build it — building it teaches you timezone handling properly — but it is a reason to be honest about which of the two you are doing.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
- Stripe — reducing your PCI scope
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.
A booking link publishes your availability to the internet. Rate-limit it before you share it.
Team booking means colleagues’ calendars depend on your cron job being awake.
A booking form is a personal-data intake endpoint that strangers fill in before you have ever spoken.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice