Should I vibe code
Booking pages, staff calendars, reminders, and Zoho integrations
The $12 isn’t buying a booking page. It’s buying the seven writes that fire when somebody books one.
?
Their verdict, the Premium 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
Eight dollars a user is not the price of a booking page — it is the price of a spoke. Zoho Bookings is cheap because the value arrives from everything around it: a confirmed appointment becomes a calendar event, a meeting link, a contact in the CRM, an SMS from a workflow, a line on an invoice and an assignment to a named member of staff, and none of that is code Zoho had to write twice. Rebuild it and you inherit that list as your integration surface. You are not writing a scheduler; you are running a small private integration bus against seven APIs you do not control, each with its own OAuth grant, its own rate limits, its own regional data centre, and its own habit of versioning without asking. The scheduling itself is the ordinary weekend the other entries here describe — slots, DST, a public form. What kills this one is slower and duller: eighteen months of somebody else's release notes, and a booking that stopped reaching the CRM three weeks ago without anyone noticing, because a silent no-op looks exactly like a quiet fortnight.
What actually breaks
not "if". the specific failures.
- The integration that nobody watches — a booking is created, the CRM write 401s, the error is logged, and three weeks of leads exist only in your database
- OAuth grants across Zoho's regional data centres, because a token issued for one domain is not valid against another and the failure message rarely says so
- API rate limits and credit budgets, which are fine in testing and hit hard the week the business gets busy
- Sync loops, when your app writes an event to a calendar, reads it back on the next poll, and creates a second booking from its own output
- Staff availability, once the schedule spans several people who add personal appointments outside your system
- Bookable resources — rooms, chairs, equipment — which turn each appointment into a two-sided allocation that a single slot table cannot express
- Reminders, quietly, the first time your cron host restarts during the window
- Feature drift, roughly quarterly, as the product you replaced ships something your users now ask you for
Is that you?
the verdict is a default, not a law
- It books one person's time, with no staff assignment and no downstream systems to keep in step
- The only integration is a calendar, in one direction, and you can name the account it writes to
- Every write to another system is idempotent, retried and alerted on failure, before the booking page goes live
- Nobody's payroll, invoicing or CRM depends on the booking existing anywhere but your database
- The business already runs on a suite and the booking has to appear in it — that is the actual product and it is not a weekend
- Several staff share a schedule and add appointments outside your system, which makes your availability view permanently a guess
- You are allocating rooms or equipment as well as people, which is a different scheduling problem than the one an agent will build you
- Nobody is on the hook for the integrations after launch, which for a side project means nobody
If you build it anyway
the checklist, then the prompt that enforces it
- Write the integrations before the booking page. If the CRM write, the calendar write and the SMS send are not idempotent, retried and alerted on, the pretty part is a demo.
- Give every downstream write an outbox row with a status, so a failed sync is a visible queue rather than a log line nobody greps.
- Tag events your own app created and skip them on the next poll. A sync loop is the classic failure and it manifests as duplicate bookings, not as an error.
- Nail Zoho's regional domains early if you are integrating for real: accounts, tokens and API hosts are per data centre, and the mismatch fails in a way that looks like a permissions bug.
- Model resources separately from people, and make the constraint cover both. A room and a practitioner both have to be free, and a single slot table cannot say that.
- Pull staff availability from each person's real calendar rather than from your own table, and fail closed when you cannot read it.
- Rate-limit the public booking endpoint per IP and per email and add a bot check, because an open form on a business's site is both a nuisance and a map of when nobody is in.
- Budget for API maintenance in advance and write down which versions you depend on. This is a subscription you pay in weekends rather than dollars.
I am building a booking system for a small business whose appointments must
also appear in other systems — calendar, CRM, invoicing, SMS. Treat the
integrations as the product and the booking page as the easy part.
1. Start with an outbox. Every downstream write is a row with a status, an
attempt count and a last error, processed by a worker with backoff. No
fire-and-forget calls from a request handler.
2. Make each downstream write idempotent on booking id plus target system, so a
retry cannot create a second CRM contact or a second calendar event.
3. Build the alert before the feature: any outbox row that fails permanently
pages me. A booking that silently never reached the CRM is the failure I care
about, and it looks exactly like a quiet week.
4. Tag events this app creates with a marker and skip them when polling, then
write the test that proves a sync cycle does not produce a duplicate.
5. Ask me which regional data centre the vendor account is in before writing any
OAuth code, and keep the auth host, API host and token store per region.
6. Model people and resources as separate bookable things. Enforce availability
with a database constraint covering both, then test booking the same room
for two different practitioners at once.
7. Read staff availability from each person's real calendar, and fail closed —
offer no slots — when a calendar cannot be read. Never assume free.
8. Reminders and confirmations are idempotent on booking id plus type and
survive a worker restart mid-window.
9. Compute availability from UTC instants plus IANA timezone ids, and test both
DST transitions before any UI exists.
10. Rate-limit the public create endpoint per IP and per email, and add a bot
check before the page is linked anywhere.
11. Collect the smallest set of customer fields that lets the appointment
happen, and build the delete path that clears the booking and every copy the
outbox pushed elsewhere.
12. Out of scope unless I ask again: payments, packages, multi-location
workspaces and staff payroll splits.
13. Finish by listing every external API this now depends on, and tell me
honestly how many hours a year keeping them working is likely to cost.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
If the business already lives in a suite, immediately. Twelve dollars a seat is roughly one hour of maintaining an OAuth integration per year, and what you are buying is that Zoho keeps their own APIs working against their own product — which is the single hardest promise your version cannot make. Build your own only if the booking is genuinely standalone, and in that case start from Cal.com rather than from an empty repo.
$12/mo is cheaper than your weekend.
The good news is that if you built it correctly there is almost nothing to migrate: the calendar holds the appointments, the CRM holds the customers, the invoicing system holds the money, and your app is an index and a UI over other people's records. Keep it that way deliberately — no state that exists only in your database — and turning it off is a redirect to a hosted booking link plus one afternoon re-pointing the embed. The thing that does not survive is your slot rules and buffers, so write those down in prose somewhere a human can reimplement them from.
Mature open-source scheduling platform with team events, availability rules and an app store of integrations to copy from.
Self-hosted appointment scheduler built for service businesses with providers, services and customers.
Questions
Several other scheduling entries here are YOUR FUNERAL. Why is this one only DEMO ONLY?
Because of what the failure costs and who it lands on. Acuity's entry is about health information in an intake form, Book Like A Boss about refunds, Setmore about two clients in one chair. The Zoho version of this, as most people would build it, holds a name, an email and a time, and its characteristic failure is a lead that never reached the CRM. That is expensive and annoying rather than dangerous — which is precisely the shape of DEMO ONLY: you will reach an impressive demo and never reach the product.
Where does the maintenance actually come from?
Not from the scheduling. From the fact that a booking has to become five other things, each behind an API with its own auth model, regional endpoints, rate limits and deprecation schedule. Nobody budgets for that because it is invisible on the day you launch. Eighteen months later it is the only part of the codebase you ever touch, and every change is somebody else's release note rather than your own idea.
Does the free tier change the calculus?
It sharpens it. Zoho Bookings is free forever for one user with calendar sync and reminders, so a solo consultant rebuilding this is competing against zero. The paid tiers begin exactly where the work does: several staff, several workspaces, payments and CRM sync. The price ladder is an accurate map of where a homemade version stops being a weekend.
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 would not be writing a scheduler. You would be writing the till at somebody else's front desk.
The double-booking isn't yours to apologise for. It's a stylist, at 9am, with two people booked into one chair.
A booking form that asks “any conditions we should know about?” is a medical record with a submit button.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice