File
SMF·VIMCAL
Received on
31.07.2026
Reviewed on
28.09.2026
Exhibits annexed
3
Questions
4

SMF·VIMCAL

Can a prompt replace Vimcal?

Scheduling — booking links and calendar automation

Almost Verdict recorded on 28.09.2026 · Verified on 31.07.2026
Price
$15/moSource: vimcal.com · Checked on July 31, 2026
Per year
$180
Build time
A week
Category
Scheduling
Votes
0 votes
YesAlmost (checked)Not yet

Exhibit tracking slip

Exhibit A The prompt
Exhibit B What you lose
Exhibit C Why people still pay: calendar integrations and reliability
Exhibit Q Questions

Verdict

The calendar client is buildable: Google's API gives you events, and a command palette over them is ordinary work. Two things make it a fortnight rather than a weekend. Time zones are genuinely hard once you handle recurring events across daylight-saving boundaries, and getting them wrong means a meeting at the wrong hour, which is the only bug in a calendar that matters. And Vimcal's speed comes from aggressive local caching with optimistic writes, which is a synchronisation problem, not a rendering one.

Exhibit B — What you lose

Exhibit A — The prompt

Received on31.07.2026
Build a keyboard-first calendar client over one Google Calendar account, with time-zone handling as a first-class concern.

Authentication: a Google Cloud OAuth client with calendar scope; refresh tokens encrypted at rest; a visible reconnect flow.

Sync: pull events with the incremental sync token API rather than re-fetching a window, store them in PostgreSQL, and keep the sync token so a restart resumes rather than refetches. Writes are optimistic — apply locally, send to Google, and reconcile or roll back visibly on failure. That optimism is what makes the interface feel instant, and the rollback path is the part that must be tested.

Time handling, done properly. Store every event in UTC with its originating time zone recorded separately. For recurring events, expand the RRULE in the event's own time zone, not in UTC, so a weekly 09:00 meeting stays at 09:00 across a daylight-saving change instead of drifting by an hour. Write tests for this specifically, including a series that crosses a DST boundary in a zone that shifts on a different date from the viewer's.

Time-zone view, which is the differentiating feature: a control that shifts the whole grid into another zone, and a secondary column showing a chosen zone alongside your own. When creating an event, type a time in any zone and see it resolved in every zone you have pinned. Show the other party's working hours as a shaded band so an 08:00 that is 23:00 for them is visible before you send the invite.

Keyboard: a command palette for everything (jump to a date, create an event, change view, switch zone), plus single-key shortcuts for day, week, month, today, next, previous. The mouse must be optional for every action.

Scheduling links: publish availability from working hours minus busy time, with buffers and minimum notice. Reserve a slot transactionally so two people booking simultaneously cannot both win, create the calendar event, and email confirmations with signed cancel and reschedule links.

Out of scope: Microsoft and Apple calendar accounts, mobile apps, team round-robin routing, payments, and any CRM integration.

Opening prefills the prompt — press enter to run it.

Exhibit B — What you lose

  • B.1 Outlook and Apple calendar accounts
  • B.2 the native desktop and mobile apps
  • B.3 team scheduling: round-robin, collective availability, routing
  • B.4 the polish around edge cases you only meet twice a year

Prior art

Exhibit C — Why people still pay: calendar integrations and reliability

Because a calendar that shows the wrong hour once has lost your trust permanently, and the time-zone edge cases are the part nobody wants to own themselves.

Questions

Is there anything to import?

No, and that is a rare advantage here. Vimcal is a client over your existing Google Calendar, so the data is already where it needs to be. Only your scheduling-link configuration has to be recreated.

Why is recurring-event time zone handling called out so specifically?

Because it is the bug every homegrown calendar ships. Expanding a recurrence in UTC looks correct in testing and moves every occurrence by an hour when the clocks change, which surfaces as people arriving late to a standing meeting for a fortnight before anyone works out why.

What does it cost to run?

A small VPS with PostgreSQL, five to ten dollars a month. The Google Calendar API is free at personal volumes. Scheduling-link emails need a transactional sender, which is free at low volume on most providers.

What is the one thing that does not survive the rebuild?

Trusting it without checking. Vimcal has had years of edge cases reported by people whose calendars are their livelihood. A self-built client that gets a half-hour-offset zone or a leap-week recurrence wrong will do so silently, and you will find out from the person waiting on the call.

Receipt

Already built this yourself?