Should I vibe code
Automatically plans tasks and projects around availability and deadlines
A wrong estimate about your own Tuesday is annoying. The same estimate about a colleague's becomes a 1:1.
?
Their verdict, the Basic 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 a priority queue with a calendar-shaped hole in it and you will have one running by Sunday lunchtime: sort by deadline, subtract meetings from the working day, fill what is left, render. Motion's entry already makes the durable point about this category — writing the scheduler is a weekend, believing it on a Monday morning six months later is the product. TimeHero adds something that changes the shape rather than the size of the problem, which is that it plans a team. The engine is not only deciding what you do on Tuesday; it decides what four colleagues do, flags which of their tasks are at risk and marks which of them are overloaded. That output looks like a measurement and is not. It is your estimator's opinion about durations that people guessed, rendered in a colour a manager will read as fact. The engineering underneath is the boring half and still larger than it looks: recurrence with exceptions, two clock changes a year, and three calendar providers that each interpret an all-day event slightly differently. Keep it advisory, keep it yours, and think hard before you give it a write token.
What actually breaks
not "if". the specific failures.
- The estimates, which are the input to everything else and are guesses. A forecast built on guesses is a very confident rendering of a guess
- The words "at risk" and "overloaded", because a number your code produced about somebody's week gets read as an observation rather than an opinion
- Recurrence. Repeating rules with exceptions, moved instances and cancelled occurrences is the single deepest sinkhole in this category and it is deeper than the scheduler itself
- Clock changes, twice a year, when every planned block lands an hour away from the meeting it was supposed to sit beside
- The write path, if you take one. Touching an event that has attendees sends mail to all of them, and no amount of reverting un-sends it
- Refresh tokens for a whole team's calendars, sitting in a table you administer alone with no rotation story
- Trust, via churn. An engine that re-plans on every change moves work people had already committed to mentally, and by week three they stop reading it
- Provider disagreements about all-day events, declined invitations and what exactly counts as busy
Is that you?
the verdict is a default, not a law
- It plans your day and nobody else's
- The calendar connection is read-only and the plan lives in your app rather than in the calendar
- It proposes, you accept — the day's plan becomes real because you agreed to it, not because a cron job decided
- One provider, one account, and a token you can revoke from a settings page you already know how to find
- It writes to calendars that other people can see, or touches events with attendees on them
- It plans other people's work and shows somebody their colleagues' capacity
- You are holding refresh tokens for a team and cannot say where they are encrypted or how you would rotate them
- The output is used in a conversation about performance, which is the point at which your priority queue became evidence
If you build it anyway
the checklist, then the prompt that enforces it
- Start read-only and stay there for a fortnight. A planner that only reads your calendar can be wrong without costing anyone anything, and you will learn more from watching it be wrong than from shipping the write path.
- When you do write, write to a calendar of your own that others subscribe to, rather than into the shared work calendar. It gives you a delete-everything button that does not touch anybody's real events.
- Never create, move or delete an event that has attendees. That is a mail-sending operation dressed as a database update.
- Give every event you create a stable identifier that you generated and stored, and match on that alone. Matching on title plus start time works beautifully until the first clock change, and then it duplicates the entire calendar.
- Freeze the next twenty-four hours. Re-planning tomorrow morning at 11pm tonight is how people stop believing the tool.
- Encrypt refresh tokens at rest, keep them out of logs and backups, and write the revoke path before the connect path.
- Test against a clock change deliberately: set the machine to the week the clocks move and run a full re-plan. Everyone in this category finds a bug there and most of them find it in production.
- Show the assumptions next to any judgement — the estimate, the available hours, the deadline used. A label that cannot be interrogated will be believed.
I am building an automatic planner: tasks with estimates and deadlines, scheduled into the
gaps around my calendar. Assume it may end up planning other people too. Build in this
order and argue when I try to hand it a write token early.
1. Read-only for the first two weeks of work. Connect the calendar, ingest events, produce a
plan, render it. Do not write anything to a calendar and refuse if I ask.
2. Model estimates as ranges with a confidence, never as single numbers, and carry that
uncertainty all the way to the display. Everything downstream inherits it.
3. Recurrence next, because it is the real work: expansion with exceptions, moved instances,
cancelled occurrences and a horizon. Write the tests before the scheduler.
4. Store timestamps in UTC with the originating timezone alongside, and add a test that runs
a full re-plan across a clock change in both directions. Show me it passing.
5. Then the scheduler, as a pure function from tasks plus busy time to a plan. No side
effects, so I can replay it over historical data and see how often it was wrong.
6. Freeze the next 24 hours by default. Explain that a planner which reshuffles tomorrow at
11pm loses the user's trust faster than one that is occasionally suboptimal.
7. Only now, if I insist, the write path — and to a separate calendar I own, never the
shared work calendar. Every created event carries an identifier you generated and stored;
never match on summary plus start time. Say plainly that this is the bug that duplicates
a calendar the week the clocks change.
8. Absolutely never create, move or delete an event that has attendees. Refuse, and tell me
it is an email to every one of them.
9. Encrypt refresh tokens at rest, keep them out of logs and exports, and implement revoke
and rotate before connect.
10. If I ask for team features, stop. Ask who reads the workload view and what happens to a
person the system marks as overloaded. Any per-person judgement must display the
estimate, the available hours and the deadline that produced it.
11. Deliberately out of scope: Gantt charts, project forecasting and capacity planning across
people — those are the parts that turn a guess into a document somebody quotes.
12. Close by telling me what $5 a seat buys, and be honest that most of it is recurrence,
timezones and provider quirks rather than intelligence.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
Anyone other than you is in it. At $5 a seat month-to-month, the entry tier costs less than an hour of the time you will spend on recurrence rules alone, and what you are buying is precisely the unglamorous part: repeating rules with exceptions, clock changes, and three calendar providers who disagree about all-day events. The single-player version is a genuinely good build and you will learn something real about your own estimates from it. The team version is a different product, and its output is opinions about colleagues — which is worth having somebody else's name on.
$5/mo is cheaper than your weekend.
Keep the tasks and treat the plan as derived. Tasks, estimates, deadlines and dependencies export to CSV or JSON and import into anything; the schedule itself is output, so throw it away and regenerate it rather than migrating it. If you ever took the write path, the exit has one extra step and you should build it now rather than later: tag every event your code created with an identifier of your own, and keep a command that finds and removes exactly those. Otherwise switching off your planner leaves months of orphaned blocks on a calendar somebody else also looks at, and you will delete them by hand.
Self-hostable open-source auto-scheduler built explicitly as a Motion alternative; its README still warns that it is buggy and in active development.
Mature open-source task app with timeboxing and time tracking, which is the planning half without the calendar write path.
Questions
How is this different from the Motion and Reclaim entries?
Motion is about believing your own scheduler over time, and Reclaim is about holding a write token to a calendar your colleagues can see. TimeHero's own twist is that the plan is about a team: it produces per-person judgements — this task is at risk, that person is overloaded — and those judgements are estimator output wearing the clothes of a measurement. That is why the guardrails here spend as much time on what the tool displays as on what it writes.
Is a read-only planner actually useful?
More useful than people expect, and it removes most of what is dangerous. Reading the calendar, computing a plan and showing it to you costs nothing when it is wrong, and you can then decide to follow it. Writing blocks into the calendar buys visibility to colleagues and costs you the ability to be wrong quietly. For a self-built version that trade is not close.
What is the bug everyone in this category ships?
Matching existing events by title and start time instead of by an identifier you generated and stored. It works for months. Then the clocks change, nothing matches, the sync recreates every block, and the newly created blocks get mirrored on the next pass. Store your own id on the event and match on that alone.
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.
Read-only calendar tools give advice. This one holds a write token to a calendar your colleagues can see.
Sunsama sells a ritual. You can build the ritual's furniture in a weekend and still not do the ritual.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice