Should I vibe code
Publish booking pages with routing rules, forms, and reminders
A booking page fails loudly. A routing rule fails silently: the form says thanks and nobody is ever assigned.
?
Their verdict, the Schedule 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
Four scheduling tools already have entries here and they break in the same three places: slot arithmetic, daylight saving, and a calendar token that stops refreshing. OnceHub's pricing points somewhere else. The $12 seat is a booking page; the product this page is named after starts a tier up, where a form asks a stranger some questions and a rule decides which of your colleagues gets the meeting. That inverts the failure mode entirely. A booking page fails loudly — an error, or two people in one doorway, and somebody complains within the hour. A routing rule fails quietly: the form submits, the thank-you renders, no branch matches, and nothing is created anywhere. The visitor believes they have a meeting. You believe nobody enquired. Neither of you finds out. Underneath that sit the two things routing structurally requires — a pool of refresh tokens for colleagues who never read your code, and free-text answers collected from strangers on a public endpoint, on a form OnceHub sells a HIPAA business associate agreement for, at six dollars a seat, because of what people write in those boxes.
What actually breaks
not "if". the specific failures.
- The default branch, which is the bug this whole category is built to hide — a rule set with no catch-all turns a qualified enquiry into a row nobody owns and a page nobody sees
- Pooled availability, the first time round-robin offers a slot from a colleague's calendar that your cached free/busy has not refreshed since breakfast
- Other people's tokens, plural: one expired refresh grant in a pool of eight means the rota keeps assigning to somebody whose calendar you can no longer read
- Daylight saving, twice a year, in the direction nobody tests — a rule that says 'business hours' evaluated against a stored offset rather than a zone name
- The intake form, which is where the sensitive material actually accumulates, because 'what would you like to discuss?' is a free-text box and strangers are candid in it
- Reassignment, when a routed meeting has to move to a different host and the invitation, the reminder and the video link were all created under the first one
- Reminders, which are the part everybody notices only in their absence and which quietly make your domain a sender
- Deletion, once a routing form has copied a person's answers into a calendar description, a notification email and an owner's inbox — three places you will have to find later
The routing form went live on a Tuesday and worked all week, which is the problem. It asked company size, budget band and what the enquiry was about, then assigned by industry to one of four people. What nobody tested was the branch for 'Other', because in testing everyone picked a real industry. Eleven enquiries chose Other across nine days. Each of them submitted successfully, saw the thank-you page and waited. No calendar event was created, no owner was set, no notification fired, and the dashboard — which counts bookings — showed a quiet fortnight rather than an error. It surfaces when one of the eleven emails the general address to ask, politely, whether the meeting is still happening. You go looking and find the rows are all there, complete, with names and phone numbers and a paragraph each about what they wanted, sitting in a table that nothing has ever read.
Is that you?
the verdict is a default, not a law
- It is one calendar, yours, and the form collects a name and an email and nothing else
- Every submission creates a durable record before any rule runs, and an unmatched rule pages a human rather than rendering a thank-you
- Availability is read live at the moment of booking, not from a cache, and the write is confirmed before the visitor sees a confirmation
- You store zones as zone names, and there is a test that runs the booking flow across both daylight-saving transitions
- You are writing events into colleagues' calendars from a public endpoint
- The form asks anything a person would be embarrassed to see quoted back — health, finances, legal trouble, a complaint about their employer
- There is a routing tree without a catch-all, or a catch-all that only logs
- A pool of long-lived OAuth refresh tokens for other people lives in a database you set up in an evening
- Nobody is watching a metric that would notice submissions arriving and meetings not being created
If you build it anyway
the checklist, then the prompt that enforces it
- Persist the submission before you route it. The form's job is to write an enquiry row and return; routing is a second step that can fail without losing anything. This single ordering prevents the failure that defines this entry.
- Make 'no rule matched' an incident, not a fallthrough. Assign to a named default owner, alert, and never show the visitor a success page for something that has no owner.
- Alarm on the ratio, not on errors. Submissions in versus meetings created out, checked daily — that is the only signal that catches a silent drop, because every individual request looked fine.
- Read free/busy live at booking time and write the event before confirming to the visitor. A cached availability window plus an optimistic confirmation is how two people end up in one slot.
- Store IANA zone names and never a UTC offset, and put both daylight-saving transitions in your test suite. Half the bugs in this category are one stored offset.
- Treat colleagues' calendar grants as the sensitive credential they are: encrypted at rest with a key held elsewhere, narrowest scope that works, a visible list of who has connected, and a revoke button that works without you.
- Ask for the least you can on the form, and write down where each answer ends up. If a free-text box can reach a calendar invitation body and a notification email, you now have three copies of a stranger's disclosure and a deletion request has three places to go.
- Build reminders on a transactional email provider with unsubscribe handling, and never on a loop in your app server.
I am building booking pages with routing forms that assign meetings across a
team. Apply these constraints in this order, and push back when I skip one.
1. Persist first, route second. A form submission writes a durable enquiry
record with all answers and a timestamp before any routing rule executes. If
routing throws, the enquiry still exists.
2. There is always a catch-all owner. If no rule matches, assign to a named
fallback, alert a human, and never render a confirmation to the visitor for an
unassigned enquiry. Refuse to build a rule engine without this.
3. Add a reconciliation job on day one: count submissions versus meetings
created, per day, and alert on divergence. Tell me plainly that individual
requests all look successful when this breaks.
4. Read calendar free/busy live at the moment of booking and write the event
before returning success. Never confirm from cached availability.
5. Store time zones as IANA names, never offsets, and write tests that run a
booking across both daylight-saving transitions before building the UI.
6. Calendar credentials for other people are the most sensitive thing here.
Encrypt refresh tokens at rest with a key outside the database, request the
narrowest scope, handle refresh failure as a loud alert that pauses that
host's assignments, and build revoke before connect.
7. Question the form fields with me. For each one, ask why it is collected and
where the answer ends up. If a free-text answer would be copied into a
calendar invitation or an email, say so — that is three copies to delete.
8. The booking endpoint is public and unauthenticated. Rate-limit per IP and per
email, and cap how far ahead anyone can book.
9. Send reminders through a transactional provider with unsubscribe handling,
never an SMTP loop in the app.
10. Out of scope: payments at booking, chatbots, SMS and multi-tenant
workspaces. Say so, and note that OnceHub's routing tier is $23 a seat with
a HIPAA agreement sold as a $6 add-on — which tells you what these forms
end up holding.
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
The moment a second person is in the rotation. A booking page for one calendar is a fair weekend project; a router that assigns other people's time is a distributed system with a public front door, and $23 a seat covers the rule engine, the token refresh, the reassignment path and the reminder infrastructure. If your form asks anything clinical or financial, buy it and buy the compliance add-on too — the fact that it exists as a line item, at $6 a seat, is the market telling you what these forms end up containing.
$12/mo is cheaper than your weekend.
Two exports, and the second is the one people forget. First, every enquiry with its answers, its routing decision and its outcome, as newline-delimited JSON — that is your record of who tried to reach you and what happened. Second, the calendar side is not yours to export: revoke each host's grant at Google or Microsoft rather than deleting rows, and confirm that events already written stay put, because deleting your database will not remove them from anyone's calendar. Then go through the three places a form answer landed — the record, the invitation body, the notification mail — and delete in all of them or you have not deleted anything.
Mature open-source scheduling platform with calendar integrations, round-robin and routing forms already built.
Self-hosted appointment scheduler with providers, services and a public booking page.
Questions
How is this different from the Calendly and Appointlet verdicts?
Calendly's entry is about the public endpoint — an unthrottled booking link is a free way for strangers to fill your week. Appointlet's is about correctness: time zones, DST and the gap between showing a slot and writing the event. OnceHub adds a layer above both. Once a rule decides who gets the meeting, the interesting failure is not a wrong slot, it is no slot at all and nobody knowing. That is a different class of bug, because every component reported success.
Is a routing form really a personal-data problem?
Look at what OnceHub sells beside it. A Security and Compliance add-on with a HIPAA business associate agreement, at $6 a seat a month, exists because customers put clinical detail into qualification forms — and the same box collects financial circumstances, employment disputes and complaints about a current supplier. You are running a public, unauthenticated collection point for volunteered disclosures from people who have no relationship with you yet, and the obligations under GDPR Art. 5 and Art. 32 attach the moment the row is written.
What is the smallest version that is actually safe to build?
One calendar, yours, a name-and-email form, live availability read at booking time, and a rate limit on the public endpoint. That is a good weekend and its worst failure is your own diary looking wrong. Everything that makes OnceHub OnceHub — pooled hosts, rules, qualification questions, reassignment — adds either somebody else's calendar or somebody else's disclosure, and those are the two things that move a scheduler out of your own blast radius.
Why does the silent drop happen so reliably?
Because nothing in the request path considers it an error. The visitor's POST returns 200, the validation passed, the row was written or wasn't, and the rule engine simply ran out of branches. Every log line reads normally, and the dashboard you built counts meetings, so a fortnight with no meetings looks like a quiet fortnight. The only thing that catches it is a reconciliation between submissions in and meetings out, which nobody writes until after the first 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.
A booking link publishes your availability to the internet. Rate-limit it before you share it.
A booking form that asks “any conditions we should know about?” is a medical record with a submit button.
Timezone maths is the product, not a feature. It goes wrong twice a year, silently, in someone else's calendar.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice