Should I vibe code
Build a fast keyboard-first calendar client with scheduling links
The whole product is that there is no confirmation dialog. That is also the bug.
?
Their verdict, the Standard 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
Vimcal's pitch is that a calendar should answer at the speed of a keystroke, and every design decision follows from that: a local copy of your calendar so nothing waits for a round trip, and single-key actions with no "are you sure". Both are lovely. Both are also what makes the homemade version unpleasant rather than merely unfinished, because the cache is a second copy of the truth and a second copy can be wrong — press `d` on the event under the cursor and you have deleted whatever the cache believed was there, which after a failed background sync is not what is on your screen. Under that sits the part nobody photographs: a Google refresh token with read and write access to every calendar you own, sitting in an environment variable, which is a credential that reads every meeting you have ever had and the name of everyone you had it with. The booking-link half brings the familiar double-booking and timezone problems, and the Calendly entry covers those properly. What is specific to this one is that the delightful part of the product and the destructive part are the same keypress.
What actually breaks
not "if". the specific failures.
- The local cache, which is a second copy of the truth and is stale at exactly the moment you press a destructive key
- Single-key actions with no confirmation, which is the feature — until a background refresh reorders the day and the selection is no longer the event you were looking at
- The Google refresh token, which lives in your environment and grants read and write on every calendar in the account
- Google's OAuth verification, which for calendar scopes puts an unverified-app warning in front of anyone you share it with and caps you at 100 users
- Recurring events, where editing one occurrence and editing the series are different writes and every user expects to be asked which
- Timezones on the booking link — the booker's zone, your zone and the DST rules on the date of the meeting are three separate problems that all look like one
- Sync latency, which turns "this slot is free on your page" into "that slot was taken four minutes ago"
- Invite and notification email, sent from your domain, which is the part nobody tests and the part attendees actually see
Is that you?
the verdict is a default, not a law
- It reads and never writes — an overlay, a launcher, a heads-up display over a calendar something else owns
- It is your own calendar, on your own machine, with no booking link pointed at the internet
- Every destructive keystroke re-reads the event from the API before acting, and undo exists before delete does
- Tokens live in the OS keychain rather than a dotfile, and you know exactly which scopes you asked for
- A single keypress deletes or moves an event using only what the cache believes
- The refresh token sits in a .env on a box you share, or in a repo, or anywhere a backup would pick it up
- You have published a booking link with no rate limit, which is a free way for anyone to fill your week
- Other people rely on it to know where to be, because their calendar correctness is now your uptime
- You asked for full calendar scope when read-only would have done
If you build it anyway
the checklist, then the prompt that enforces it
- Request the narrowest OAuth scope that works, and start read-only. Adding write access later is a decision; starting with it is an accident.
- Store tokens in the OS keychain or a secret manager, never in a dotfile next to the code. A calendar token is a credential, not a config value.
- Re-read the event from the API immediately before any destructive action, and compare it to what is on screen. Refuse to act if they differ.
- Build undo before you build delete. Keep the event body you removed so you can put it back — the Google API will not do that for you.
- Use incremental sync tokens rather than polling, and treat a sync failure as a reason to disable destructive shortcuts until it recovers.
- Handle the recurring-event fork explicitly: this occurrence, this and following, or the whole series. Never guess on the user's behalf.
- Store every time as UTC plus the originating timezone, and write the DST tests before the UI. The autumn hour is not a hypothetical.
- If there is a booking link, rate limit it, and hold a slot with a database constraint rather than checking availability and then writing.
I am building a keyboard-first calendar client over the Google Calendar API,
for myself, possibly with a public booking link later. Speed is the point, so
there will be a local cache and single-key actions. Build it so a fast keypress
cannot destroy a real meeting, and push back when I ask for speed over safety.
1. Start read-only. Ask for the narrowest scope that works and render the week
before you write anything. Make me explicitly ask for write access.
2. Tokens go in the OS keychain or a secret manager. If I suggest a .env file,
tell me that this token reads every meeting and attendee in my account.
3. Undo comes before delete. Keep the full event body of anything removed and
give me a single key to restore it. Build this first, not last.
4. Every destructive action re-reads the event by ID from the API and compares
it to what the cache showed. If they disagree, refuse and re-render.
5. Treat the cache as disposable. Use incremental sync tokens; on any sync
error, disable destructive shortcuts and say so in the UI until it recovers.
6. Recurring events fork explicitly — this occurrence, this and following, or
the series. Never infer which one I meant.
7. Store instants in UTC with the originating timezone alongside. Write the DST
tests, including the repeated hour in autumn, before the calendar grid.
8. If I add a booking link: rate limit it, reserve slots with a unique database
constraint rather than check-then-write, and never expose event titles or
attendees on the public page — only busy and free.
9. Tell me about Google's OAuth verification requirements for calendar scopes
before I plan to share this with anyone, including the unverified-app screen.
10. Out of scope unless I ask: team calendars, availability sharing across
accounts, and anything that writes to somebody else's calendar.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 your calendar is how you are paid — back-to-back days, other people booking you, timezone juggling every week — $20 a month is cheap for a client somebody else keeps correct across Google's API changes. The homemade version is a good project and a fine read-only overlay; it becomes a poor deal the moment it is the only thing standing between you and a meeting you did not know about.
$20/mo is cheaper than your weekend.
Nothing here is yours to lose, which is the comfortable part: the calendar lives in Google, and deleting your client leaves every event exactly where it was. Two things do need care. Revoke the OAuth grant when you stop using it rather than just deleting the code, because the token keeps working. And if you published a booking link, keep the URL alive and redirect it — it is in email signatures and other people's notes, and a dead scheduling link fails silently at the other end.
Mature open-source scheduling platform with calendar integrations and booking workflows.
Long-running command-line Google Calendar client with agenda views, search and event creation — the keyboard-first half without the UI.
Questions
How is this different from the Fantastical entry?
Fantastical's entry is about the two problems that eat calendar apps from the inside: recurrence rules and CalDAV sync. Those apply here too. What is specific to Vimcal is the interaction model — a local cache for speed and single keys for actions, with no confirmation step — which turns a stale read into a deleted meeting rather than a display glitch. Same category, different failure.
Read-only really is the safe version?
Yes, and it is also most of the value. A fast keyboard overlay that shows you the week, jumps to a date, searches events and copies your availability as text does not need write access at all, and cannot lose anything. Ask for read-only scope, build that, use it for a month, and only then decide whether writing is worth the class of bug it introduces.
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