Should I vibe code
Create a polished Apple calendar client with natural-language event entry and local sets
Natural-language event parsing is delightful. Recurrence rules are a war crime.
?
Their verdict, the Premium Individual 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
Parsing “lunch with Sam next Thursday” is a solved and satisfying problem. Everything about repeating events across timezones is not.
What actually breaks
not "if". the specific failures.
- Recurring event exceptions, where editing one occurrence of a series is a different write from editing the series and users expect to be asked
- CalDAV sync, an old protocol with per-server quirks and etag-based conflict handling you have to get exactly right
- Natural-language parsing, which is delightful in the demo and wrong in the ways that matter — 'next Friday' during a week that contains a Friday
- Timezone-bearing events, especially all-day events, which are the classic off-by-one across a date boundary
- Writing back, because a sync bug in a read-only client is a display glitch and in a writing client is a deleted meeting
You type 'move standup to 10' and your parser resolves it against the series rather than Thursday's instance. The write goes to CalDAV as an update to the recurring master, and every standup for the next year shifts an hour — including the ones colleagues had already declined and rescheduled around. The sync is flawless. It faithfully propagated exactly what you asked for to eleven people's calendars, and the undo you did not build is the feature you now need.
Is that you?
the verdict is a default, not a law
- It is read-only — a beautiful view over a calendar something else writes to
- It creates simple non-recurring events and edits nothing
- You are the only user and you know precisely which quirks you have not handled
- It edits recurring events
- It writes to shared or work calendars other people rely on
- There is no undo for a natural-language action
- You are handling all-day events without an explicit timezone strategy
If you build it anyway
the checklist, then the prompt that enforces it
- Read-only first, and stay there longer than feels necessary. A sync bug that only displays wrongly costs nothing.
- For recurring events, always ask: this occurrence, this and future, or the whole series. Never infer it — this is the single most damaging assumption in calendar software.
- Use a maintained CalDAV and iCalendar library. Recurrence expansion with EXDATE and RECURRENCE-ID is not somewhere to be original.
- Show the parsed result before committing. Natural language is a suggestion, and the confirmation step is what makes it safe to be wrong.
- Treat all-day events as floating dates, not midnight timestamps, and write a test that crosses a date boundary from a different timezone.
- Honour etags on write and surface conflicts rather than overwriting. Two clients editing one event is normal, not exceptional.
Before you build a calendar client, apply these and push back if I ask you to break them. 1. Build read-only first and tell me to live with it for a while. Explain that a sync bug in a viewer is a cosmetic problem and the same bug in a writer deletes other people's meetings. 2. Use an established CalDAV client library and an iCalendar parser. Do not implement recurrence expansion, EXDATE or RECURRENCE-ID handling yourself. 3. Any edit to a recurring event must ask explicitly whether it applies to this occurrence, this and all future, or the entire series. Never infer. Tell me this is the most common way calendar tools destroy data. 4. Treat all-day events as floating dates without a time or zone. Write a test that renders one while the device is in a timezone behind UTC and assert the date does not shift. 5. Store timed events as UTC plus the IANA zone, and preserve the original zone from the source event rather than normalising it away. 6. For natural-language input, always show the parsed interpretation — date, time, duration, calendar — and require confirmation before writing. The parser will be wrong about relative dates and confirmation is what makes that harmless. 7. Honour etags and If-Match on every write. On conflict, show me both versions rather than overwriting. 8. Implement undo for any action created from parsed text. 9. Out of scope unless I ask: invitations and RSVP handling, free-busy lookup, attachments, shared calendar management.
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
At $4.75 a month this is one of the cheapest entries on the list, and what it buys is a decade of CalDAV quirks and recurrence edge cases already handled. A read-only viewer you build for yourself is a lovely project; a writing client is where the time goes.
$4.75/mo is cheaper than your weekend.
Because the events live in CalDAV on someone else's server, the data is never trapped — which is the good news here. Keep any local-only metadata exportable and avoid storing meaning in fields the server does not carry, so uninstalling your client leaves the calendar intact.
Mature open-source scheduling platform with calendar integrations and booking workflows.
Questions
Why are recurring events the dangerous part?
Because one user action has three plausible meanings and only one is right. Editing Thursday's standup could mean Thursday, or every future Thursday, or all of them including past ones. Guessing wrong writes to a shared calendar and propagates to everyone who subscribes — and there is rarely an undo.
Is natural-language parsing worth building?
Yes, with a confirmation step. Parsing 'lunch with Sam next Thursday at noon' is genuinely achievable and delightful. The mistake is committing straight from the parse — relative dates are ambiguous even between humans, and showing the interpretation before writing turns a wrong guess into a corrected one.
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.
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