Should I vibe code
Run group availability polls and convert the selected option into a calendar event
A poll link is a public roster of who's free when. That isn't a bug in Doodle — it's the design you're copying.
?
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
A grid of proposed times with checkboxes is the friendliest-looking hard problem in scheduling. The poll is an afternoon. Then somebody in Denver votes on a slot you created in Berlin, for a date after the US clocks change and before the European ones do, and the two of you are looking at different meetings while reading the same row. Underneath that sits the model itself: a link anybody can open, which is the feature, and which makes the page a public roster of named people and when they are free.
What actually breaks
not "if". the specific failures.
- Timezones. A slot stored as '15:00' is not a time, and a poll spanning a clock change shifts by an hour for exactly the participants who do not share your country's changeover date
- The poll URL, which by design needs no account — so a sequential or guessable id turns your service into a directory of who is free when
- Vote editing. If anyone with the link can change any row, then anyone with the link can change any row, including deleting the votes the decision rested on
- Email. Invitations and reminders mean sending mail to people who never signed up, from a domain with no sending reputation to spend
- Calendar write-back, which is where a cheerful afternoon project turns into OAuth token lifecycle management
- Deadline and reminder jobs — a cron you will deploy once and forget, still emailing strangers a year later
Is that you?
the verdict is a default, not a law
- Participants all work with you and the poll is for a coffee, not a board meeting
- Poll ids are unguessable and polls actually expire
- No name or email outlives the poll it belonged to
- Participants are external and their names and availability would matter if a crawler found them
- Anyone holding the link can edit or delete anyone else's votes
- It sends bulk reminder email from a domain whose deliverability you care about
- You store times as local wall-clock strings — fix that one before anything else on this list
If you build it anyway
the checklist, then the prompt that enforces it
- Store every option as a UTC instant plus the IANA timezone it was authored in, render in each viewer's own zone, and show the zone name on screen. Never store a wall-clock string.
- Generate poll ids with a CSPRNG, at least 128 bits, never sequentially. The link is the entirety of your access control, so it had better be unguessable.
- Give each participant a private edit token in their own link. Otherwise the poll URL is edit access for everyone who ever receives a forward.
- Put an expiry on every poll and delete on it. A finished poll is a list of names, addresses and availability with no remaining purpose.
- Send noindex headers and a robots rule on poll pages before the first poll goes out, not after you find one in a search result.
- Rate-limit vote submission and hide participant details by default. A public write endpoint on a public URL gets found.
I am building a group availability poll — participants open a link and tick the times that work. Apply these constraints before any UI.
1. Model time correctly before anything else. Every option is a UTC instant
plus the IANA timezone it was created in. Refuse to store local wall-clock
strings, and explain that a poll spanning a daylight saving change is the
specific case that breaks.
2. Render every option in the viewer's own timezone with the zone name
visible, and show the author's zone too. Never display a bare time.
3. Poll identifiers come from a CSPRNG, at least 128 bits, never sequential
and never derived from a title. The link is my only access control.
4. Each participant gets a separate private edit token in their own link.
Holding the public poll link must never grant the ability to change or
delete somebody else's vote.
5. Add noindex and nofollow headers on poll pages and a robots.txt rule, from
the first commit. A poll page is a roster of named people and their
availability.
6. Every poll carries an expiry, with a scheduled job that really deletes
participants, votes and emails afterwards. Build the deletion job before
the creation form.
7. Rate-limit vote submission per IP and per poll, cap the number of
participants, and cap field lengths. Assume the endpoint will be found by
something automated.
8. Do not collect email addresses unless a feature genuinely requires one, and
if reminders exist, make them opt-in per participant with a working
unsubscribe. I do not want to become a bulk sender by accident.
9. Default to hiding other participants' names and votes until someone has
voted, and make full anonymity an option on the poll.
10. If I ask for calendar write-back, stop and explain the OAuth token
lifecycle I am taking on, then build it read-only first.
11. Out of scope, and say so rather than approximating: recurring polls,
payments, and any kind of attendee tracking across polls.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 polls involve people outside your organisation, or the meeting that comes out of one is worth money. Doodle Pro is around $15 a month on monthly billing and the things you are buying are deeply unglamorous: correct timezone handling, calendar write-back that survives token expiry, and reminders that leave from a domain with a sending reputation. Cal.com is the open-source route if you would rather own it and are willing to run it.
$14.95/mo is cheaper than your weekend.
There is barely anything to exit, and that is the honest good news. Polls are ephemeral by nature, so the exit plan is deletion: make sure finished polls genuinely disappear, and that the meeting you eventually agreed lives in a real calendar rather than only in your database.
Mature open-source scheduling platform with calendar integrations; the timezone and OAuth work is already done and tested.
Questions
Isn't the timezone thing overstated?
It is understated. Polls usually propose dates weeks out, which is exactly when an offset baked in at creation time goes wrong: the US, the EU and the southern hemisphere change clocks on different dates, and no error is ever raised. Everyone simply sees a time, and some of those times are wrong.
Why does a public poll link matter if the poll is boring?
The poll is boring; the aggregate is not. A page listing named people, their email addresses and when they are unavailable on Thursday is a small intelligence product. Because there is no account by design, the only things standing between it and a crawler are whether your ids are guessable and whether you remembered noindex.
What's the honestly-fine version of this?
Internal polls, unguessable ids, no email collection, and automatic deletion a week after the deadline. That version is close to a ship-it, takes an afternoon, and never becomes something a stranger's name lives in longer than it needed to.
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.
Team booking means colleagues’ calendars depend on your cron job being awake.
Natural-language event parsing is delightful. Recurrence rules are a war crime.
TidyCal is twenty-nine dollars once. Yours is a weekend now and a calendar-API migration every spring.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice