Should I vibe code
Desktop calendar combining tasks, scheduling, and focus planning
Rise deleted the tasks when it shut down. The calendar survived — because it was always Google's.
?
Their verdict, the Teams (final list price) 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
There is no buy option here. Rise announced its shutdown in January 2025, switched off at the end of March, and deleted every project and task it held along with its own copies of everyone's calendars. What it could not delete were the events themselves, because those always lived at Google and Microsoft — and that is the design lesson the closure handed out for free. A calendar client that treats the provider as truth and itself as a view can be abandoned on any Tuesday with no consequence beyond an uninstall. Rise's own additions were the parts that evaporated. Build on that principle and the rest of this is an honest weekend project with a long tail: recurrence rules and timezones will take longer than the whole UI did, they always do. The part to be careful with is the write path. Reading a calendar is pleasant. Auto-scheduling means your code creating, moving and deleting events, and any of those on an event with attendees is an email to every one of them.
What actually breaks
not "if". the specific failures.
- Recurrence. RRULE with exceptions, a single moved occurrence, a rule spanning a DST change, an all-day event in a timezone that is not yours — this is where "nearly finished" becomes a fortnight, and it is not negotiable because everyone's calendar has a standup in it
- Multi-provider sync. Google's incremental sync tokens expire and mean a full resync, Microsoft Graph has its own delta semantics and its own idea of a series master, and iCloud is CalDAV, which will remind you what CalDAV is
- Writes with attendees. Moving an auto-scheduled block that happens to have one guest emails that guest; a planner that reshuffles your afternoon four times emails them four times
- The difference between an event you own and one you were invited to. Deleting the first cancels it for everybody, deleting the second declines it, and getting that backwards sends a cancellation to eight people who then all reply
- Token refresh at the worst possible moment. A grant that expires while you are asleep is a calendar that quietly stopped syncing, and the first symptom is a meeting you did not know about
- Task-and-event duality. If a task is also a block on the calendar, one of them has to be the truth, and every bug in this category comes from having answered that question twice
- Team availability, which means holding OAuth grants for colleagues — a completely different risk category from holding your own
- The offline cache, which is a second copy of the truth and therefore a second opportunity to be wrong about what is under the cursor
Is that you?
the verdict is a default, not a law
- The provider is the source of truth and your app is a view over it
- It reads. Anything it writes, you confirmed on that specific event
- It is your calendars only — no colleague's token has ever touched it
- Whatever you invent on top (tasks, focus blocks, plans) is mirrored into something that outlives the app
- A scheduler moves events unattended and any of them have guests
- You keep the only copy of tasks in your own database with no export you have tested
- It holds refresh tokens for other people's calendars
- You have not yet written a test for a weekly recurring event across a DST boundary, because that is the bug and it is waiting
If you build it anyway
the checklist, then the prompt that enforces it
- Provider as truth, always. Your database holds a cache plus whatever you invented; if the two disagree, the provider wins and you resync. This single decision is what makes the project abandonable.
- Read-only for the first version, and mean it — no create, update or delete anywhere in the codebase until the read path has survived a month of your real calendar.
- Do not implement RRULE. Use a maintained library, and write the test suite against a set of real events including exceptions, a moved occurrence, an all-day series and a DST crossing.
- Store times as UTC plus the originating IANA timezone, never as a local wall-clock string. Every calendar bug that is not recurrence is this one.
- Before any write, check whether the event has attendees, and require explicit confirmation if it does. Silent reschedules are emails you did not know you sent.
- Distinguish organiser from attendee at the model level, not at the call site, so "delete" cannot mean "cancel for everyone" by accident.
- Handle token expiry as a first-class state with a visible banner. A sync that silently stopped looks exactly like a week with no meetings.
- Mirror your own inventions into the calendar or into flat files as you create them, so the day you stop running this you still have your tasks.
I am building a desktop calendar that merges tasks with events and can plan
focus blocks. Two rules over everything: the calendar provider is the source of
truth, and any write may generate email to other people. Work in this order.
1. Read-only first, end to end, and stop there until I say otherwise. No
create, update or delete code exists in the repository yet.
2. Model the provider as truth and my database as a cache plus my own
inventions. On any disagreement, refetch. Write that rule as a comment where
the sync runs.
3. Use a maintained RRULE library; do not hand-roll recurrence. Before any UI,
show me passing tests for a weekly series crossing DST, a moved occurrence,
a deleted occurrence, an all-day event, and a series edited from the middle.
4. Times are stored as UTC plus the IANA zone the event was created in. A local
wall-clock string anywhere in the schema is a bug — fail the build on it.
5. Model organiser and attendee as distinct states. Deleting an event I organise
cancels it for everyone; deleting one I was invited to declines it. Make it
impossible to call the wrong one.
6. Any write to an event with attendees requires my explicit confirmation,
showing who will be emailed. If I ask for automatic rescheduling, refuse
once and describe the four-notifications-in-an-afternoon case.
7. Tokens go in the OS keychain, never a config file. Expiry is a visible app
state with a banner, because a silently stopped sync looks identical to a
quiet week.
8. Handle Google sync-token invalidation and Graph delta expiry explicitly, with
a full resync path that is tested rather than theoretical.
9. Everything I invent on top — tasks, plans, focus blocks — is exportable to a
flat file from day one and mirrored to the calendar where that makes sense.
Rise deleted its users' tasks on shutdown; my own app can do that to me too.
10. Out of scope until I ask: other people's calendars, team availability and
booking pages. The moment a colleague's token is in here, the risk stops
being mine.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
You cannot buy this one — Rise is gone, refunds included. If what appealed was the calendar-plus-tasks combination, the live equivalents are on this site: Morgen and Motion for automatic scheduling, Vimcal if what you wanted was speed. The more useful takeaway is the one the shutdown handed over free of charge: choose the tool whose export you could actually use, and try that export before the email arrives rather than after. Rise gave its users two months and a working export page, which is more than most.
Rise wrote the exit plan for everybody when it switched off: the events were fine because they lived at Google and Outlook, and the tasks were gone because they lived at Rise. Copy that split deliberately. Anything the provider can hold — events, reminders, even a planned focus block — should exist as a real calendar entry, not as a row you own. Anything genuinely yours belongs in a flat file you can read without your own app, written as you go rather than exported on the way out. Then abandoning the project means uninstalling it and revoking one OAuth grant, and the calendar carries on exactly as it did before you started.
Mature open-source scheduling platform and a working reference for multi-provider calendar OAuth.
Maintained iCalendar parser and recurrence expander, and the reason not to write RRULE handling yourself.
Questions
Rise shut down — why is there still a pricing page?
Because the marketing site was never taken down. risecalendar.com serves the sunset notice on the homepage while /pricing still cheerfully offers Solo free and Teams at €10 a seat. It is a good reminder that a live pricing page is not evidence that anyone is home; the announcement, the app subdomain and the last release are better signals, and here all three point the same way.
What is genuinely hard about a calendar app?
Recurrence and timezones, in that order, and they are hard in a way that does not feel hard until you are three weeks in. A weekly event that crosses a DST boundary, a series where one occurrence was moved, an all-day event created in a different zone, a series edited from the middle onwards — every calendar system in the world has bugs in that region, which is why the advice is to use a library and write the tests first.
Is auto-scheduling really that risky for a personal tool?
It is risky in one specific way: notifications. Rearranging your own solo blocks is harmless and quite satisfying. The moment a block has one guest on it, every move your planner makes is an email in somebody else's inbox, and a planner is designed to make many small moves. Keep automatic rescheduling for events with no attendees and the whole feature becomes safe.
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.
The whole product is that there is no confirmation dialog. That is also the bug.
A booking link that takes a deposit is a shop. Refunds, no-shows and coupon codes are your accounting now.
A booking link publishes your availability to the internet. Rate-limit it before you share it.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice