ChoreChart
A household chore tracker: parents assign and approve, kids check chores off and earn points toward rewards.
- Status
- Personal use
- Launched
- July 2026
- Built with
- Next.js, TypeScript, Tailwind CSS, Supabase, PostgreSQL (PL/pgSQL)
Overview
ChoreChart is a chore-tracking app for our household. Parents assign and approve chores; kids check them off and earn points toward rewards.
It was built for our own family, two parents and two kids, rather than as a general product, and we've used it every day since it launched in July 2026.
The problem
Paper charts and verbal reminders didn't stick. There was no fair way to split a reward that two kids wanted to save up for together, and no record of what got done, when, or who approved it.
What I built
ChoreChart has separate views for parents and kids. Parents create and edit chores, each with a title, points, icon, frequency, time-of-day window and optional pause dates, and maintain a catalog of rewards. When a kid marks something done, it lands in an Approvals queue for a parent to approve or reject.
Kids see today's chores, tick them off, and watch their points total and streak grow. They can browse rewards and request one, either on their own or split with a sibling.
A Stats page shows completion history and streaks over any date range. An Overview page lets parents step backward and forward through any day, including previewing chores scheduled in the future, and see points earned against points available.
Key features
- Parent and kid views
- Parents manage and approve; kids see today's chores and their progress.
- Flexible scheduling
- Daily, weekly or once-off chores, with time-of-day visibility windows and pause-until dates.
- Approvals queue
- Nothing counts until a parent approves it.
- Parent overrides
- Mark done, skip or unapprove when real life doesn't match the chart.
- Points and rewards
- A rewards catalog kids can browse and request from.
- Split rewards
- Two kids can save toward one reward; every participant signs off before a parent sees the request.
- Streaks and stickers
- Streaks earn a sticker-chart reward.
- Overview and stats
- Step through any day, past or future, and see completion history and points available per day and week.
Interesting problems
Split rewards, entirely in Postgres
Requesting a split reward, dividing the points evenly (any odd remainder goes to the requester), checking that every participant can afford their share, and deducting each kid's own balance on approval all happen in one atomic SECURITY DEFINER function. I didn't want a partial split to be possible if the app crashed mid-request, and I didn't want the client to be the only thing deciding whether everyone could afford it.
An RLS infinite recursion that hid from me
Two row-level security policies, one on reward_redemptions and one on reward_redemption_participants, each queried the other table to decide whether a co-participant could see a shared request. Postgres detected the cycle and errored, but only under a real user's row-level security. The service-role access I was using to debug bypassed RLS entirely, so it never reproduced. It took a genuinely broken production feature before I found the exact error message pointing at the recursion.
Decisions & trade-offs
Permission checks in database functions, not scattered policies
Sensitive actions (approve, reject, skip, split-approve) all go through SECURITY DEFINER Postgres functions that check the caller's role themselves, rather than relying on broad client-side RLS policies. It means more logic in SQL, but there's one place to trust instead of permission checks spread across server actions.
One hard-coded family timezone
ChoreChart will never be multi-tenant, so a single family timezone replaces per-user settings.
No native app or push notifications
It's a responsive web app. Everyone already has it bookmarked, and that's been enough.
Outcome
Both kids and both parents have used it daily since launch.
The biggest visible change is that the kids actually check a shared reward and negotiate splits with each other, which never happened with the old system.
What I learned
How much of “it doesn't work” turns out to be infrastructure, like a disconnected Vercel Git integration or a stale RLS assumption, rather than application logic. The split-reward bug looked exactly like a broken feature for days, and was neither.
Tech
- Next.js
- TypeScript
- Tailwind CSS
- Supabase
- PostgreSQL (PL/pgSQL)
Screenshots
