Should I vibe code
Manage personal tasks, lists, reminders, recurring items, and a daily planning flow
iOS lets an app queue 64 pending notifications. Your recurring reminders silently fall off the end of that list.
?
Their verdict, the Premium 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
A list with checkboxes is the canonical weekend project and there is nothing here that can hurt anyone — worst case you lose a shopping list and your own goodwill. Where a homemade version diverges from Any.do is not the list, it is the reminder: Any.do is a nagging app more than a database, and nagging is the part that lives outside your code. iOS caps pending local notifications at 64 per app, so a handful of daily-recurring tasks quietly truncates the tail and the reminder you needed most is the one that never fires; Android's Doze will happily defer your alarm past the moment it mattered. Neither failure logs anything. That is genuinely worth knowing before you start, and it is still not a reason not to build this. Keep the tasks in a file you can read without your app, put a real recurrence library between you and RRULE, and enjoy it.
What actually breaks
not "if". the specific failures.
- Reminders, silently — the iOS 64-notification ceiling and Android Doze both drop the alarm without an error, and a task app that stops nagging is indistinguishable from one with nothing due
- Recurrence, at the edges everyone hits: the last day of the month, the 29th of February, "every second Tuesday" after you skip one, and every rule that crosses a DST change
- Sync, the moment there is a second device — two offline edits to the same task need a merge rule, and last-write-wins quietly eats the other one
- Shared and family lists, which turn a single-user data model into a permissions model overnight
- Natural-language date parsing, which is the demo feature and is wrong in a way that puts things in the wrong week
- Your own enthusiasm, which is the real maintenance risk: the app has to keep working on the day you have stopped enjoying it
Is that you?
the verdict is a default, not a law
- It is yours, on your devices, and the data is a file you can open in a text editor
- Reminders are a convenience rather than the thing standing between you and a missed flight
- You are happy to use a real recurrence library instead of writing date maths
- There is an export, and you have run it at least once
- Someone else's medication, deadlines or school run depend on a notification your code schedules
- You are adding shared lists and had not planned to write a permissions model
- The only copy of your tasks lives in an app database with no backup and no export
If you build it anyway
the checklist, then the prompt that enforces it
- Store tasks in a plain, readable format — Markdown, JSON, SQLite with a documented schema — so the data outlives your interest in the project.
- Use an established RRULE library. Recurrence is a solved problem with a specification, and hand-rolled "every two weeks" logic breaks on the first skipped occurrence.
- Schedule notifications lazily: keep only the next few per task on the OS queue and top them up on launch. Assume the 64-slot iOS budget and design within it.
- Do not let the notification queue be the source of truth. Recompute what is due from the task list on every launch, so a dropped alarm shows up as an overdue item rather than as nothing.
- If sync exists, give every task a stable id and a per-field updated-at, and decide the conflict rule deliberately. Last-write-wins is fine — knowing you chose it is the point.
- Ship export before sharing. A CSV or Markdown dump takes an hour and turns abandoning the project into a non-event.
I am building a personal task manager with reminders and recurring tasks, for myself. The risk here is not danger, it is silent unreliability — a reminder that never fires looks exactly like a day with nothing due. Design against that.
1. Data first: define a plain, documented storage format I can read without the app, and
write the export before the UI. Markdown or JSON on disk, or SQLite with the schema
written down.
2. Use a maintained RRULE library for recurrence. Do not write date arithmetic by hand.
3. Before any recurrence UI, write tests for: the 31st in a 30-day month, 29 February,
"every second Tuesday" with one occurrence skipped, and a weekly rule crossing both DST
transitions in my timezone.
4. Assume a hard cap of 64 pending local notifications on iOS. Schedule only the next
occurrence or two per task and refill the queue on launch and on background refresh.
5. The notification queue is a cache, never the source of truth. Recompute what is overdue
from the task list at every launch so a dropped alarm surfaces as an overdue item.
6. Add a diagnostics screen listing every pending OS notification with its fire date, so I
can see when the queue and the tasks disagree.
7. Store due dates as a date plus an IANA timezone, not a UTC instant, for all-day tasks.
A task due Friday should be due Friday after I fly somewhere.
8. Give every task a stable UUID from the first commit, even if there is no sync yet.
9. If I ask for sync, ask me for the conflict rule before writing any of it, and implement
per-field updated-at rather than whole-record last-write-wins.
10. Deletion is a tombstone with an undo window, not a DELETE. The most common bug in a
task app is losing something you meant to keep.
11. Out of scope unless I ask again: shared and family lists, collaborators, calendar
write access and natural-language date parsing. The first two turn this into a
permissions model and the last is wrong more often than it looks.
12. Finish by telling me what I am giving up for eight dollars a month: cross-device sync
somebody else operates, and notification delivery they have already fought the OS over.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 need it to work on a phone, a laptop and a partner's device, and you need the reminders to be reliable rather than mostly reliable. Eight dollars a month buys sync you do not operate and push delivery someone else has already argued with two mobile operating systems about. It is also the honest answer if the reason you want to build a task app is that you are avoiding the tasks — the best todo list is the one you are not maintaining.
$7.99/mo is cheaper than your weekend.
Trivial if you keep the promise about storage. Tasks in Markdown or JSON on disk, synced by whatever file service you already pay for, means abandoning the app costs you a UI and nothing else — the list is still readable in any text editor and importable into Todoist, TickTick or Any.do in an afternoon. The version with an exit problem is the one where tasks live in an opaque local database with no export, at which point deleting the project deletes two years of recurring routines you no longer remember.
Mature open-source task and project manager with lists, kanban, and recurring work.
Open-source Android task app with recurrence, reminders and CalDAV sync, and a useful reference for how notification scheduling is actually handled.
Questions
Is there anything here that isn't just a todo list?
The reminders, and they are most of the reason people pay. A task list is a table; a reminder is a promise that an operating system designed to save battery will wake your app up at a specific moment. iOS gives an app 64 pending local notification slots and drops the rest without complaint, Android's Doze defers alarms to preserve battery, and neither failure produces an error you can catch. Everything else about this build is as easy as it looks.
Do I need to build sync?
Probably not, and skipping it is the single biggest reason this stays a SHIP IT. Put the tasks in a file in a folder that iCloud Drive, Dropbox or Syncthing already replicates and you get eighty per cent of multi-device for none of the work. Real sync means conflict resolution, a server, an account system and a schema you can migrate — which is exactly the point where a weekend project becomes a product you operate.
What about shared or family lists?
That is a different app. A shared list means permissions, invitations, someone else's data on your server and the expectation that a reminder fires for a person who cannot debug it. Any.do charges separately for Family for a reason. If you want shared lists, that is the moment to pay somebody rather than to add a table.
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.
Natural-language date parsing is the only hard bit, and it is a solved library.
Tasks, habits, a timer. Three small features you will actually use because you chose them.
Merging tasks and calendar is easy. Merging them without one corrupting the other is not.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice