Should I vibe code
Schedule household chores by flexible frequency and show a neutral shared history
The schema is one table. The hard part is getting your flatmate to install your build.
?
Their verdict, the Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
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 danger here to manufacture. A chore tracker is one table of tasks, each with an interval and a last-done date, and a screen that sorts by how overdue things are — an evening, and a pleasant one, with nothing at stake but a list of rooms in your own house. Two honest notes instead of a warning. The first is that Tody's actual invention is not the schema but the decay model: tasks do not fall due on a day, they get progressively dirtier, so missing Tuesday does not produce a red overdue badge that makes you close the app. Copy that behaviour rather than building a repeating to-do list, because the repeating to-do list is the version people abandon in nine days. The second is social, and it is the real reason homemade versions die: the product only works when everyone in the house is in it, and your partner is not going to sideload your APK. If the household matters, the paid feature is sync — which is also the one genuinely hard piece of engineering, since two phones marking the kitchen floor done while offline is a merge problem, not a save.
What actually breaks
not "if". the specific failures.
- Adoption, which is the only failure that matters — an app one person in the house has is a private to-do list with extra steps
- The decay curve, if you model chores as due dates: one missed week turns the whole screen red and you stop opening it
- Sync, the moment there are two phones, because both will mark tasks done offline and something has to decide what happened
- Timezones and local dates, which is how a task completed at 11pm shows as done tomorrow and resets a streak
- Notifications, once background scheduling meets Android's battery optimiser and iOS's idea of when your app may run
- The database, sitting in app storage on one phone, holding two years of history and one OS reinstall away from gone
- Your own enthusiasm, roughly three weeks in, which is the failure mode of every self-built habit tool and is worth planning an export for
Is that you?
the verdict is a default, not a law
- It is for your household and the data never leaves the devices in it
- You are happy to lose the history — the current state of the house is what matters, not the audit trail
- You want the decay model tuned to your own standards rather than someone else's defaults
- One person using it is already useful to you
- You need everyone in the house on it and they already use something that works
- You were planning to publish it to the stores, which turns a weekend into store review, crash reports and a support inbox
- Assignments and rotations are the point, because fair distribution between people is a negotiation with a UI attached, not a scheduler
If you build it anyway
the checklist, then the prompt that enforces it
- Model dueness as a continuous score, not a due date. Store last-completed and an interval, compute staleness on read, and let tasks age gracefully past their window.
- Local-first storage with a real export. One JSON or CSV file with task, area, interval and completion history means the project surviving your interest is a copy, not a migration.
- If you add sync, give every completion a stable id and a device clock, treat the log as append-only, and resolve duplicates by keeping the earliest — two people finishing the same chore should not fight, it should be idempotent.
- Keep completions as events rather than overwriting a last_done field. It costs nothing and it is what makes streaks, history and undo possible later.
- Compute everything in local dates, not UTC instants, and write a test for a task finished at 23:50.
- Schedule notifications sparingly and test them on a phone with battery optimisation on, which is where they quietly stop.
- Seed the task library. The reason the commercial apps feel instant is that they already know a bathroom has six chores in it, and a blank list is where a household app dies.
I am building a household chore tracker for me and the people I live with.
There is nothing sensitive here, so the constraints are about the shape of the
thing rather than safety. Build in this order.
1. Start with a task library, not an empty list. Seed rooms and common chores
with sensible intervals so the app is usable in two minutes.
2. Model dueness as a continuous staleness score computed from last-completed
and an interval. Do not implement chores as calendar events or repeating
to-dos with due dates, and push back if I ask for that — the red-overdue
screen is why these apps get deleted.
3. Completions are append-only events with a stable id, a local date and a
person. Never overwrite a last_done column.
4. Local storage only in v1. No account, no server, no analytics.
5. Build JSON and CSV export, and a single command that wipes everything,
before you build any charts or streaks.
6. Do all date arithmetic in local dates. Write a test for a chore completed
at 23:50 and one for a device that crosses a timezone.
7. Only after the single-user app works, and only if I ask, add sync. When I
do: make completions idempotent by id, treat the log as append-only,
resolve duplicate completions of the same chore on the same day by keeping
the earliest, and never make the newest write win.
8. Notifications come last, are limited to one digest a day by default, and
are tested with Android battery optimisation enabled.
9. Do not build assignment or rotation until the tracking works. Fairness
between housemates is a conversation, and an algorithm that hands my
partner the bathroom three weeks running is a bug in my relationship.
10. Out of scope, and say so rather than stubbing it: accounts, cloud backup,
gamification, app store packaging, and anything shared outside my home.
11. Finish by telling me Tody's free tier is feature complete for one person
and Premium is about ten dollars a year, so I know what I am replacing.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
At roughly ten dollars a year, the arithmetic is not close, and the two things you are buying are the ones your build will not have: everyone in your house can install it in thirty seconds from a store they already trust, and the sync between their phones is somebody else's problem. Build your own if you want to tune the decay model to your own standards or you simply enjoy it — this is a lovely small project. Buy it if the goal is that the kitchen actually gets cleaned.
$0.83/mo is cheaper than your weekend.
One SQLite file or one JSON document, exported to somewhere you keep things, and the project is fully reversible. What is actually worth keeping is not the completion history — nobody misses that — but the task list itself: rooms, chores and the intervals you tuned over six months. That list is the only thing you would rebuild from memory badly, and it pastes straight into Tody, Grocy or a spreadsheet.
Self-hosted household ERP with a proper chores module — periodic tasks, assignment and completion tracking — if you would rather run something than write it.
Questions
Why not just use repeating tasks in my to-do app?
Because a repeating to-do fires on a date and then sits there accusing you. Tody's model is that cleanliness decays: a task gets gradually more overdue and the list re-sorts itself, so a skipped week changes the priority order instead of producing a screen full of failures. That difference is the entire product, and it is about ten lines of arithmetic — which is exactly why it is worth copying rather than reinventing.
Is household sync really the hard part?
It is the only part with a wrong answer. Two people, two phones, both offline in a house with patchy wifi, both tapping done on the same chore, then both reconnecting — if the newest write wins you lose a completion, and if you naively append you get duplicates and a broken streak. Make completions idempotent by id and the problem mostly evaporates. It is not incidental that sync is the feature Tody charges for.
Should I put this on the App Store?
Only if you want a different hobby. Publishing turns a weekend project into review cycles, crash reports from devices you do not own, and an inbox of people who found your app and now expect it to keep working. For your own household, a local build on the family's phones — or a small web app on the home network — gets you everything and commits you to nothing.
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.
Your family is not a beta cohort. They share your address and they remember the appointment your app dropped.
Port-forwarding your house is a decision, not a feature.
Recipes, meal plans, a grocery list. The stakes are dinner.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice