Should I vibe code
Automatically schedules flexible tasks around calendar commitments
Re-solve from scratch each run and you get a different day every time you look. You stop believing it by Thursday.
?
Their verdict, the Core 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
SkedPal is a constraint solver wearing a to-do list, and the demo is unfairly good: rank tasks, read the gaps between meetings, watch a week assemble itself in three seconds. What the product is actually selling is stability. Re-plan everything from scratch on every change and you get a different Thursday each time you open the app, and a plan you cannot trust is worse than the list you started with — so the real engineering is hysteresis and minimal diffs, not scheduling. Under that sits two-way calendar sync, which means the solver's output is a stream of mutations against a real calendar, authorised by a refresh token with write scope sitting in an .env on a box you set up on a Sunday. The saving grace, and the reason this lands a band gentler than Reclaim, is scope: SkedPal fits your own tasks into your own time, so nothing it does puts mail in a colleague's inbox. Build the read-only version that tells you honestly the week does not contain the hours you have promised. That is most of the value and none of the write path.
What actually breaks
not "if". the specific failures.
- Plan stability, which is the actual product. A solver that re-derives everything on each pass produces a schedule that differs every time you look at it, and you quietly stop reading it
- The diff between one plan and the next, which has to become the smallest possible set of calendar edits. The obvious implementation deletes and recreates every block, churning event ids and anything holding them
- Duration estimates, the solver's only real input, supplied by a human who is famously bad at them — optimistic in, confidently scheduled nonsense out
- Two-way sync, the first time you drag a block in Google Calendar and the next run drags it back, at which point you are arguing with software about your own afternoon
- The time map itself, which is a set of weekly recurring rules, so it inherits every recurrence and daylight-saving bug there is
- The OAuth refresh token with calendar write scope, which is the single most valuable file in the project and lives wherever you left it
- Sync token expiry, where the provider answers 410 GONE and expects a full resync, and naive change detection responds by re-creating everything it has ever made
- Overflow, which is the only interesting case: when the week does not fit, a real product tells you what got dropped, and a weekend build silently schedules nothing and says nothing
Is that you?
the verdict is a default, not a law
- It only reads. A planner that tells you where your focus blocks could go and lets you drag them in is genuinely useful and carries almost 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 with attendees, so nothing it does can generate a notification for another person
- The task list and the time map live in a plain file you can read without the app
- It writes to your primary work calendar, where every block is visible to colleagues deciding when you are free
- It runs unattended on a schedule and you are not reading what it did before the next pass
- It can move or delete events it did not create, which is one predicate away from cancelling a real appointment
- You are about to let a colleague use it, which puts their calendar data in your database and moves you two entries across to Reclaim
If you build it anyway
the checklist, then the prompt that enforces it
- Start read-only and stay there for a week. Compute the plan, print it, and drag the blocks in by hand. Most of the value of auto-scheduling is being told the week does not fit.
- When writes arrive, they go to one calendar the app created. Ask for the narrowest scope the provider offers, and never the account-wide write grant if a single-calendar one exists.
- Stamp every event you create with your own id in the provider's extended properties, and treat anything without that stamp as untouchable. Write that test before the solver exists.
- Add hysteresis: do not move an existing block unless the new plan is better by a threshold you set. A solver optimising for the best answer produces the worst experience.
- Express each run as a minimal diff — create, update, delete — and never as delete-everything-then-recreate. Churned event ids break every device and integration downstream.
- Use a real recurrence library for the time map and write daylight-saving tests before any scheduling UI. Working hours are an RRULE and they shift by an hour twice a year.
- Cap writes per hour and per day from config, add a kill switch that stops all writes without a deploy, and make 410 GONE a designed path rather than an exception you retry.
- Make the overflow case loud. When tasks do not fit, the app must say which ones and why, because silent dropping is how you find out in a fortnight.
I am building an auto-scheduler that fits my tasks into the gaps in my calendar and writes
them back as events. The write token and the churn are the risks, not the solver. Build in
this order and refuse the shortcuts.
1. Start read-only. Version one authenticates with a read scope, computes the plan and prints
it as a table. Do not request write scope until I have used that for a week.
2. Keep tasks, estimates and the time map in a plain file I can edit and back up. The
scheduler reads it; it is not a database I can only reach through your UI.
3. Use an established constraint solver or a documented greedy algorithm with explicit rules.
Tell me which, and make the rules readable, because I will need to argue with the output.
4. Model the time map as recurrence rules and use a real RRULE library. Add daylight-saving
tests for a weekly working-hours rule before any scheduling code exists.
5. When writes arrive, they go to a single calendar the app creates and owns. Never my primary
calendar. Ask for the narrowest scope the provider offers.
6. Stamp every created event with an application id in extended properties. Anything without
that stamp is immovable — no edit, no delete, ever. Write this test first.
7. Hard-refuse to modify or delete any event that has attendees. If I ask for meeting
rescheduling, say that it sends mail that cannot be recalled and build propose-and-confirm.
8. Each run produces a minimal diff against the previous plan. No delete-and-recreate passes.
Add hysteresis so a block only moves when the improvement exceeds a threshold I set.
9. Treat 410 GONE on a sync token as a designed path: full resync, reconcile against my stamped
ids, create nothing you cannot prove is missing.
10. Enforce a write budget per hour and per day from config, plus a kill switch that halts
writes without a deploy. On breach, stop and tell me.
11. When the plan does not fit, say so explicitly and list what was dropped and why. Never fail
silently to schedule something.
12. Out of scope, and say so plainly: team scheduling, public booking links, reading a
colleague's calendar. Those make me a processor of other people's data.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 want the solver to be somebody else's problem, which is a reasonable thing to want — around $10 a month buys a scheduler that has survived every daylight-saving weekend since 2015 and a calendar integration reviewed by the platform it talks to. The cheaper answer, if what you actually want is honesty about the week rather than automation, is the read-only planner: a script that reads free/busy, sums your committed hours against your estimates and tells you the truth. That is an evening, it never writes anything, and it captures most of what makes this category feel good.
$9.95/mo is cheaper than your weekend.
Because tasks, estimates and the time map live in a file rather than a schema, the exit is mostly a copy command: that file imports into SkedPal, Motion, a paper planner or nothing at all. The calendar side needs the same discipline as the build — every event you created carries your stamp in extended properties, so one script enumerates and removes exactly your own footprint and leaves the real appointments untouched. Write that script while you are writing the writer, not on the day you want your calendar back.
Apache-licensed constraint solver for scheduling and rostering problems, and the honest answer to writing your own planner.
Open-source task manager with timeboxing, day planning and time tracking, local-first and worth reading before you start.
Questions
Reclaim is your funeral and Motion is demo only. Why does this one sit lower than both?
Blast radius. Reclaim's headline features act on events other people share — it reschedules meetings with guests, publishes availability links and mirrors between accounts, and every one of those sends mail that cannot be recalled. SkedPal's Core plan syncs one calendar for one person and puts your own tasks into your own gaps. The solver is the same and the write token is the same, but nothing it does lands in a colleague's inbox, and that is the difference between a bad afternoon and an incident.
Is the read-only version actually useful?
More than you would expect, and it is the version worth building. Most of the value of auto-scheduling is being told plainly that the week contains thirty-one hours of commitments and eighteen hours of space. That is a report over free/busy data with a read scope, it can run for years untouched, and you can act on it with a mouse. Everything on this page that is above a three exists because of the write path.
What is the part that actually blows the estimate?
Making the plan stable. Scheduling tasks into gaps is a short piece of code; producing a plan that resembles yesterday's plan, so a human can build a day around it, is the hard part, and it is not a scheduling problem at all — it is a diffing and hysteresis problem. Get that wrong and the app is technically correct and completely useless, which is the classic shape of a demo that never becomes a product.
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.
A wrong estimate about your own Tuesday is annoying. The same estimate about a colleague's becomes a 1:1.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice