Should I vibe code
Self-host a team booking service with event types, availability, and routing
Team booking means colleagues’ calendars depend on your cron job being awake.
?
Their verdict, the Teams 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
The open-source version is right there and self-hosting it is the sensible path. Round-robin assignment and availability merging are more subtle than they look.
What actually breaks
not "if". the specific failures.
- Collective availability, which is an intersection across several calendars and is empty far more often than anyone expects
- Round-robin fairness, which needs state — who got the last one, who is on holiday, who is at capacity
- One member's expired calendar token, so they read as fully free and absorb every booking
- Per-member timezones, so 'business hours' is five different windows and the intersection shifts twice a year
- Onboarding a new team member, which is an OAuth dance you have to support for every provider they use
Priya's Google token expired quietly three weeks ago. Your availability query treats a failed calendar fetch as no events, so she appears completely free — and round-robin, seeing the emptiest calendar, routes everything to her. She arrives on Monday to eleven meetings booked over work she had already scheduled, none of which she agreed to, all of which have external attendees who have blocked out the time.
Is that you?
the verdict is a default, not a law
- You self-host cal.com itself rather than writing a team scheduler
- The team is one person, which makes this the Calendly problem instead
- Availability is a fixed shared pattern rather than an intersection of live calendars
- A failed calendar fetch is treated as availability
- Round-robin assigns without persisted fairness state
- Team members span timezones
- External clients book through it
If you build it anyway
the checklist, then the prompt that enforces it
- A calendar fetch that fails means unavailable, never free. This single rule prevents the characteristic failure of team scheduling.
- Alert on token expiry per member, and exclude a member from the pool until their calendar is readable again.
- Persist round-robin state — last assigned, current load, out-of-office — rather than deriving fairness from whoever looks emptiest.
- Compute availability per member in their own timezone, then intersect. Never apply one business-hours window to everybody.
- Hold the slot with a database constraint at booking time, same as any single-user scheduler, and re-verify every member's calendar inside that transaction.
- Self-host cal.com before writing this. It is open source, and the team logic is exactly the expensive part.
Before you build team scheduling, apply these and push back if I ask you to break them. 1. Ask me why I am not self-hosting cal.com, which is open source and already solves round-robin, collective availability and provider sync. If I have no specific reason, tell me to do that instead. 2. Treat any failed or errored calendar fetch as fully busy, never as free. Explain that the opposite default causes the classic failure: a member with an expired token appears empty and absorbs every booking. 3. Monitor token validity per member and remove them from the assignment pool the moment their calendar cannot be read, with an alert to them and to me. 4. Persist round-robin state explicitly — last assigned timestamp, current load, out-of-office windows. Do not infer fairness from who currently looks least busy. 5. Compute each member's availability in their own IANA timezone and then intersect. Never apply a single business-hours window across a distributed team. 6. Enforce the booking with a database-level constraint, and re-verify every required member's calendar inside the booking transaction before confirming. 7. Support per-member OAuth onboarding and re-consent as a first-class flow, because it will happen repeatedly. 8. Show the booker honest availability. If the intersection is empty for two weeks, say so rather than showing an empty calendar that looks broken. 9. Out of scope unless I ask: payments, routing forms, workflows, SMS reminders.
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
For a team, effectively always — either the hosted product at $15 a seat or self-hosting the open-source original. The single-user version is a reasonable weekend; the team version is round-robin fairness and multi-calendar intersection, which is where the price comes from.
$15/mo is cheaper than your weekend.
Keep event UIDs, member assignments and round-robin state exportable, and keep booking links on your own domain. Since cal.com is open source, treat migration toward it as the likely path and avoid data shapes that only your scheduler understands.
Mature open-source scheduling platform with calendar integrations and booking workflows.
Questions
Why does a failed calendar fetch default to 'free' so often?
Because the naive implementation asks for events and gets back an empty list on error, and an empty list of events reads as an empty calendar. The distinction between 'no meetings' and 'could not check' has to be made deliberately, and it is exactly the kind of thing that never comes up until someone's token expires.
Is collective availability really that hard?
The intersection itself is simple; what surprises people is how often it is empty. Five calendars with normal meeting loads across two timezones can have almost no common free time, and a booking page showing nothing for a fortnight looks broken rather than honest — so you end up building fallbacks, priorities and overrides.
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.
Natural-language event parsing is delightful. Recurrence rules are a war crime.
A booking link publishes your availability to the internet. Rate-limit it before you share it.
Calendar clients live or die on sync correctness, which is unglamorous and unforgiving.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice