Should I vibe code
Scheduling links and meeting polls with personalized booking pages
zcal gives the entire solo product away. Your weekend is competing with free, and losing by Sunday.
?
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
Start with the price list, because it settles most of the argument. zcal gives the entire individual product away — unlimited links, meeting polls, group events, custom questions, embedding, three calendar providers and Stripe payments, all on the free tier — and charges only when you want a team page, round robin, SMS and your own branding. A solo build is therefore not competing with $10.50 a month; it is competing with zero, and it loses on features by the second afternoon. What is left worth saying is about the half nobody scores: the poll. zcal's other shape is Doodle-ish, a link where several named people mark when they are free, which makes the page a small readable map of a group's week sitting at a URL. Everyone treats that as harmless because it looks like a grid of ticks, and it is — right up until the guest list is the interesting part, and the four names on a poll titled "Q3 restructure prep" are the leak rather than the times. Short poll IDs are how that gets found. Build it to learn timezone arithmetic and OAuth refresh, which are genuinely worth learning. Schedule real meetings on theirs.
What actually breaks
not "if". the specific failures.
- Poll URLs, if the identifier is short or sequential — the names on a poll are often more sensitive than the times
- The invitee list on a group poll, which shows every participant to every other participant unless you deliberately hide it
- The Google or Microsoft refresh token, which stops refreshing quietly and leaves the page offering slots you are already busy in
- Availability across a DST transition, because the rule shifts by an hour twice a year and nothing errors
- The public create endpoint, unthrottled, which is a free way for a stranger to fill your week or map when you are free
- The confirmation and reminder emails, the first time a retry sends the same person two different times for the same meeting
- Feature parity, roughly monthly, as the thing you rebuilt keeps shipping the features you skipped
Is that you?
the verdict is a default, not a law
- It is a poll only — no calendar connection, no OAuth token, no stored refresh credential
- The links are for your own time and you can name everyone who has one
- Poll and booking identifiers are long random tokens, and you have checked what happens when someone increments one
- You are doing it to understand timezones and calendar APIs rather than to avoid a bill
- The identifiers are sequential, or derived from the meeting title, which is the same thing with extra steps
- You are holding calendar credentials for anyone other than yourself
- The page is going in an email signature, which means the create endpoint is public forever and needs rate limiting you have not written
- The reason is the subscription, because the individual plan you are replacing costs nothing
If you build it anyway
the checklist, then the prompt that enforces it
- Make every public identifier a long random token. A poll or booking link is a bearer credential and the only thing standing between a stranger and a group's schedule.
- Decide explicitly whether poll participants can see each other. Default to hidden, because the list of who was invited is frequently the confidential part.
- Store the calendar refresh token encrypted, and alert yourself when a refresh fails. Silent token expiry is the failure everyone hits and nobody notices.
- Compute availability from UTC instants plus an IANA timezone, then write DST tests for a recurring weekly rule before you build any UI.
- Rate-limit booking creation per IP and per email address before the link goes anywhere public, and add a bot check.
- Make confirmations and reminders idempotent on booking id plus type, so a queue retry cannot tell someone two different things about the same meeting.
- Give polls an expiry and a delete that actually removes the responses, since a poll is personal data about people who never signed up for anything.
I am building scheduling links plus Doodle-style meeting polls against my own
calendar. Treat every public URL as a bearer credential and push back when I ask
for something guessable or chatty.
1. Start with identifiers, before any page exists. Poll ids and booking ids are
at least 128 bits of randomness, base62-encoded. Never sequential, never
derived from the meeting title or my name.
2. Ask me up front whether poll participants should see each other's names and
responses. Default to no, and explain that on a poll the guest list is often
more sensitive than the availability.
3. Model time as UTC instants plus an IANA timezone id on both sides. Write DST
tests for a weekly recurring availability rule crossing both transitions
before you write the booking form.
4. Enforce non-overlap with a database constraint on organiser plus time range,
not an application-level check, then write the test where two people book the
same slot in the same 300 milliseconds.
5. Calendar tokens: encrypted at rest, refreshed on a schedule, and a failed
refresh disables the public page rather than silently serving stale
availability. A page offering slots I am already busy in is the bug I care
about most.
6. Rate-limit the create endpoint per IP and per email address, and add a bot
check, before you hand me an embeddable snippet.
7. Confirmations and reminders are sends: idempotent on booking id plus type,
with a log of what went where.
8. Build deletion before display. One call clears the poll, its responses, the
booking rows, the calendar events and any queued reminders.
9. Collect a name and an email and nothing else, unless I justify each extra
field out loud.
10. Deliberately out of scope unless I ask again: teams, round robin, SMS,
payments and branded domains. Each of those is a separate product.
11. Finish by telling me that zcal's free tier already includes polls, group
events, embedding and Stripe payments, and ask whether I am building this to
learn something or to avoid a bill that does not exist.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 always, and unusually the honest advice here is not "pay the $10.50" but "use the free plan". Paid starts mattering only when you have a team page, round robin across colleagues, SMS reminders or a booking page that must not say zcal on it — and those are exactly the features that make a homemade version stop being a weekend and start being a product.
$10.5/mo is cheaper than your weekend.
Keep the calendar as the system of record: every confirmed booking should exist as a real event with the invitee on it, so switching off your app loses the link and not the meetings. Polls are the part that exists nowhere else, so export them as JSON — question, options, responses, timestamps — or accept that they vanish. Because zcal's individual tier is free, the migration itself is a redirect from your old link to a new one and an afternoon spent updating email signatures.
Mature open-source scheduling platform with booking pages, availability rules and calendar sync; self-hostable.
Open-source meeting poll tool that covers the Doodle-shaped half of this product without touching a calendar credential.
Questions
If the mechanics are a single sitting, why isn't this SHIP IT?
Because a booking link is not a local tool. It is a public endpoint anyone can hit, holding a credential that can read and write your calendar, sending mail on your behalf, and telling strangers when you are free. None of that is dangerous exactly, but all of it is ongoing — and the thing you would be replacing costs nothing. SHIP IT is for builds where the worst case is deleting a repo.
What is actually risky about a meeting poll?
The times are boring; the roster is not. A poll page usually renders every invited person's name and often their email, and the URL is the only access control. Short or sequential ids turn that into something enumerable, and the titles people type into polls are startlingly candid — hiring loops, board prep, redundancy planning. If you build one, make the ids long and random and default to hiding participants from each other.
Is any part of this worth building?
The poll is. It needs no OAuth grant, no calendar write and no stored credential, which removes most of what makes this entry blue rather than green — and Rallly already exists if you would rather run one than write one. The calendar-connected booking page is the half that quietly turns into a maintenance subscription payable in weekends.
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.
TidyCal is twenty-nine dollars once. Yours is a weekend now and a calendar-API migration every spring.
A booking that issues an invoice is bookkeeping. There is no rollback — only a credit note with your name on it.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice