Should I vibe code
Personalized scheduling pages and workflows for sales meetings
Availability is not a calendar query. It is a distributed-systems problem wearing a date picker.
?
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
The demo is the honest part: a booking page, a Google OAuth grant, free/busy in, an event out. You will have that working before dinner and it will feel finished. What it isn't is a scheduling product, because scheduling is a correctness problem dressed as a CRUD app. Availability has to be computed against a calendar that changed while the visitor was reading the page, in a timezone that shifts on a different date in Auckland than it does in Chicago, for a person whose working hours are stored as local wall-clock time and whose Friday is somebody else's weekend. Every one of those is a known-hard problem with a well-documented right answer, and none of them shows up in testing because you are testing from one machine in one timezone in the middle of the week. lemcal's actual product is round-robin across a sales team plus the lemlist tie-in; your version's actual product is a double-booking you find out about from the person sitting in reception.
What actually breaks
not "if". the specific failures.
- Double bookings, in the seconds between the page rendering a slot and the visitor clicking it — the race nobody writes a test for
- Daylight saving, twice a year, in both hemispheres, on dates that do not line up, for slots stored as UTC against working hours stored as wall-clock
- The OAuth refresh token, which expires or gets revoked, after which your page confidently offers every hour of every day because free/busy returned nothing
- Cancellations and reschedules made in the calendar rather than on your page, which your database never hears about
- Recurring events and all-day entries, which come back from the API in shapes your busy-time maths did not anticipate
- The public booking endpoint, once a bot finds it and fills your week with meetings from addresses that do not exist
- Invite delivery, quietly: an ICS attachment that Outlook renders as a file instead of an event is a meeting nobody has
Is that you?
the verdict is a default, not a law
- It books one person's calendar, in one timezone, for people who already know them
- The event is created directly in the calendar provider and your database is a log rather than the source of truth
- A missed or duplicated booking is an apology, not a lost deal
- You are happy re-authorising the calendar connection by hand when it lapses
- It routes across a team — round-robin is where the availability maths stops being arithmetic
- Bookings take payment, because now a refund exists and the meeting has a price
- Prospects book it during a sales cycle and a double-booking costs someone a deal
- Nobody would notice for a week if the calendar connection silently stopped returning busy times
If you build it anyway
the checklist, then the prompt that enforces it
- Make the calendar provider the source of truth and re-check availability at confirmation time, inside the same request that creates the event. The slot list on the page is a hint, never a reservation.
- Store the working hours as a timezone plus local wall-clock time, never as UTC offsets, and use a maintained tz database rather than arithmetic on hours.
- Alarm on the OAuth connection: if free/busy returns empty or errors, the correct behaviour is to show no slots, not every slot. Fail closed.
- Subscribe to calendar change notifications and reconcile on a schedule, so a meeting moved in Google is not still confirmed in your database.
- Rate-limit and CAPTCHA the public booking endpoint, and require the invitee to confirm by email before the event is created.
- Send a real calendar invite from the provider rather than an ICS file you assembled, and test it against Outlook specifically.
- Write the DST tests first, with fixtures on the actual changeover weekends in two hemispheres. They are the ones that catch things.
I am building a booking page: visitors see my availability and pick a slot,
which creates an event on my calendar. Treat availability as a correctness
problem, not a UI problem, and order the work that way.
1. Before any code, write the timezone model down for me to approve: working
hours as a named timezone plus local wall-clock, slots as instants, a
maintained tz database, and no manual offset arithmetic anywhere.
2. Then the DST tests, with fixtures on the real changeover weekends in both
hemispheres, before any booking flow exists. If they are hard to write, the
model in step 1 is wrong.
3. The calendar provider is the source of truth. My database is a log of what I
did, never the authority on what is free.
4. Re-check availability at confirmation, inside the request that creates the
event, and return "that slot just went" rather than confirming
optimistically. Write the concurrent-double-booking test.
5. Fail closed on the connection: if free/busy errors or the OAuth grant has
been revoked, show no slots and alert me. Never fall back to showing my whole
week as free — put that in a comment where it matters.
6. Store refresh tokens encrypted and build the re-authorisation flow now,
rather than discovering it the week the grant lapses.
7. Handle recurring events, all-day entries and tentative responses in the
busy-time maths, and tell me which cases you chose to ignore.
8. Create the event through the provider so it sends a real invite rather than
an ICS attachment Outlook renders as a file, and reconcile on a schedule so
a meeting I moved in Google stops being confirmed here.
9. The booking endpoint is public: rate-limit per IP and per email, require an
email confirmation click before the event is created, and cap bookings per
day. A bot filling my week is the first abuse to arrive.
10. Out of scope, and say so rather than half-building it: team round-robin,
paid bookings and CRM sync. Round-robin is where availability stops being
arithmetic, and where lemcal's free tier starts looking sensible.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's calendar is involved, or the moment money attaches to a slot. Nine dollars a seat is roughly the cost of one double-booked prospect call, and the free tier covers a single person with three meeting types, which is most of what a solo build actually delivers. What you are renting is not the page — it is somebody else's decade of arguments with recurring events and daylight saving.
$9/mo is cheaper than your weekend.
Because the events live in Google or Microsoft rather than in your app, the exit is unusually cheap and that is worth designing for deliberately: every booking already exists on a real calendar, so deleting your service loses the booking page, not the meetings. Keep the booking-page config in a file you can read, keep a CSV of upcoming bookings with the invitee's email, and put a redirect on the old URL — the one thing that genuinely hurts is a link in a hundred email signatures that suddenly 404s the week you switch.
Mature open-source scheduling platform with round-robin, buffers and calendar sync already solved, self-hostable and worth reading before you write availability maths.
Questions
Google's API returns free/busy. How hard can availability be?
Free/busy is the easy half. The other half is your rules: working hours in a named timezone, buffers before and after, minimum notice, maximum bookings per day, rolling windows, holidays, and the invitee's timezone rendered correctly on a phone that disagrees with its own browser. Each is small. Together they are the part of the product that takes months, and daylight saving quietly invalidates whichever subset you got right.
What is the failure that actually costs something?
A revoked OAuth grant with an availability function that treats an empty response as "nothing is busy". Your page then offers every hour of every day, strangers book them, and you find out from someone waiting in reception during a meeting you were already in. Fail closed and this entry gets a lot less interesting.
Is a booking page really an abuse surface?
It is an unauthenticated endpoint that writes to your calendar and emails an address of the caller's choosing. Without a confirmation click and a rate limit, that is a free scheduler for anyone and a small mail relay for the determined. Confirm the invitee's address before the event exists and most of it goes away.
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.
The overlay is the product. Drawing it means holding a stranger's calendar credential, for the sake of a nicer grid.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice