Should I vibe code
Smart calendar scheduling for habits, tasks, breaks, and meetings
Read-only calendar tools give advice. This one holds a write token to a calendar your colleagues can see.
?
Their verdict, the Starter 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
The scheduler is not the dangerous part. Sorting tasks by deadline and dropping them into free/busy gaps is an afternoon, and it feels wonderful the first time it works. The dangerous part is the OAuth scope, because Reclaim does not read your calendar and offer advice — it holds a write token and edits a calendar that other people can see, book into, and get notified about. Its actual feature list is a list of things that touch other humans: habits that recur, sync that mirrors events between two accounts, buffer time inserted around meetings you did not create, scheduling links that publish your availability to strangers, and Smart Meetings that move appointments other people already accepted. Every one of those is an outbound email you cannot recall. Motion, next door, is rated demo-only because its blocks are mostly its own. This is the same solver pointed at a shared corporate calendar, and that is a different verdict.
What actually breaks
not "if". the specific failures.
- Recurrence. RRULE with EXDATE, a single moved instance of a weekly series, an event that spans a daylight-saving boundary — this is the part of the calendar spec that has eaten entire teams, and habits are nothing but recurrence
- The sync loop. Mirror events from calendar A onto calendar B and the mirrors immediately look like source events on B; without an indelible provenance marker, every pass creates another generation
- Attendee notifications, which are the one truly irreversible output. Moving an event with guests emails all of them, at whatever hour your cron chose, and there is no unsend
- The write token itself: a refresh token with full calendar scope on a work Google Workspace account, sitting in an .env file on a box you set up on a Sunday
- Sync tokens going stale. Google answers 410 GONE and expects a full resync, and a full resync through naive change-detection logic re-emits everything you have ever created
- Scheduling links, which publish availability derived from event data — and "busy 14:00–15:00 on Thursday" leaks more about a person than they agreed to share with a stranger holding a URL
- The boundary between events it owns and events it must not touch, because a habit-defender that mistakes a real appointment for its own block does not warn you first
The bug is three lines long and it lives in your dedupe key. Calendar sync mirrors every event from your work account onto your personal one as a busy block, and you match existing mirrors on summary plus start time, which held up beautifully for five months. Then the clocks go back. Every recurring event in your timezone shifts by an hour, none of the mirrors match any more, and the sync creates the whole set again — and because the newly created blocks are now real events on the personal calendar, the next pass mirrors those too. By the time your phone gives up rendering, there are nine hundred blocks. Deleting them is tedious but fine. What you cannot delete is what the scheduler did in between: with the day now showing as solid conflict, the meeting-rescheduling logic did its job and moved four appointments to the following week, which sent eleven people a calendar update at 4:12 in the morning. Two of them are clients. One of them is now free at the time your standup used to be.
Is that you?
the verdict is a default, not a law
- It only ever reads. A tool that tells you where your focus blocks could go, and lets you drag them in yourself, is genuinely useful and carries none of this
- Every write lands on one dedicated calendar the app created and owns, and nothing else on the account is writable
- It never touches an event that has attendees, so nothing it does can generate an email
- It runs unattended against a work calendar, because unattended plus write scope plus recurrence is the exact combination in the scenario above
- It can move, delete or reschedule events with guests — that is the one action on a calendar with no undo
- You are syncing two accounts and your matching logic is anything softer than an immutable id you stamped yourself
- You would put it in front of colleagues, at which point their meeting titles and availability are in your database and your employer has opinions about that
If you build it anyway
the checklist, then the prompt that enforces it
- Stamp every event you create with your own id in the provider's extended properties, and treat any event without that stamp as untouchable. Write that test before the scheduler exists.
- Request the narrowest scope that works, and if the platform offers a single-calendar grant, take it. A token that can only write to a calendar you made is a different security story from one that can empty the account.
- Refuse, in code, to modify or delete any event with an attendee list. Log the intent, show it to a human, and let the human press the button.
- Make sync one-directional per pair and mark mirrors so they can never be re-mirrored, then test the DST weekend and a moved instance of a recurring series explicitly.
- Rate-limit writes hard — a ceiling per hour and per day, read from config — plus a kill switch that stops all writes without a deploy. Runaway loops are the failure mode, and the cap is what turns nine hundred events into twenty.
- Handle 410 GONE on the sync token as a first-class path: full resync, reconcile against your own stamped ids, create nothing you cannot prove is missing.
- Use a battle-tested recurrence library. Do not expand RRULE yourself, and never store an expanded series as rows you then have to keep in step.
I am building a calendar auto-scheduler that writes to my real calendar:
habits, task blocks, buffer time, and syncing between two accounts. The write
token is the risk, not the solver. Build in this order and refuse the shortcuts.
1. Start read-only. The first version authenticates with a read scope, computes
the plan and prints it. Do not request write scope until I have used the
read version for a week.
2. When writes arrive, they go to one calendar the app creates and owns. Never
my primary calendar. Ask for the narrowest scope the provider offers.
3. Stamp every created event with an application id in extended properties. Any
event without that stamp is immovable — no edit, no delete, ever. Write this
test first.
4. Hard-refuse to modify or delete any event that has attendees. If I ask for
meeting rescheduling, tell me every such change sends mail that cannot be
recalled, then build propose-and-confirm instead.
5. Use an established RRULE library. Do not expand series into stored rows. Add
tests for a daylight-saving boundary, a moved instance, and an EXDATE.
6. For two-way sync, build one direction at a time. Mirrors carry an immutable
source id and are excluded from being mirrored again. Test the weekend the
clocks change and every start time shifts by an hour.
7. Enforce a write budget — events per hour and per day, from config — plus a
kill switch that halts writes with no deploy. On breach, stop and notify.
8. Treat 410 GONE on a sync token as a designed path: full resync, reconcile
against my stamped ids, create nothing that is not provably absent.
9. Route every write through one function that logs the before-state, then
build the undo script that reads that log.
10. Out of scope, and say so plainly: public scheduling links, multi-user
support, reading a colleague's calendar. If I want those, tell me I am now
processing other people's data and Reclaim is twelve dollars a seat.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
The moment anyone else's calendar is involved. Twelve dollars a seat buys a company that has already survived every daylight-saving weekend, holds an OAuth grant reviewed by Google, and gets blamed instead of you when a meeting moves. If it is only your own focus time you want defended, build the read-only version and drag the blocks in yourself — that captures most of the value and none of this page.
$12/mo is cheaper than your weekend.
The undo script is the exit plan, which is why it belongs in the build rather than in a panic. Because every event you created carries your id in extended properties, you can enumerate and delete exactly your own footprint and leave the real calendar untouched. Keep the plan itself — habits, task durations, preferred hours — as a plain config file rather than rows in your database, and moving to Reclaim, Motion or a paper notebook is an afternoon.
Open-source scheduling platform; useful prior art for calendar OAuth and scheduling workflows.
Questions
Motion is demo-only and this is your-funeral. They look like the same product.
They solve for different things. Motion's blocks are mostly its own, on your calendar, and the worst case is churn you find annoying. Reclaim's headline features are meeting rescheduling, cross-account sync and public availability links — all of which act on events other people share, and all of which send mail. The solver is identical. The blast radius is not.
What is the single most dangerous line of code here?
The one that decides an event is yours to move. Everything downstream — deleting, rescheduling, mirroring — depends on that predicate being right, and if it is based on the title, the colour or the creator field rather than a marker you stamped yourself, it will eventually be wrong about an appointment you made in person.
Is the read-only version actually useful?
More than you would expect. Most of the value of auto-scheduling is being told, honestly, that the week does not contain the hours you have committed to. That is a report, not a write token, and it is a weekend project you can leave running for years.
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.
Writing the scheduler is a weekend. Believing it at 8am on a Monday six months later is the whole product.
A booking link publishes your availability to the internet. Rate-limit it before you share it.
The overlay is the product. Drawing it means holding a stranger's calendar credential, for the sake of a nicer grid.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice