KidsChores

The problem

This started as a fork of a Home Assistant integration, and the integration model constrained it badly. Chores had to be entities. The interface was whatever the dashboard framework permitted. Anything resembling a multi-step workflow — a child claims a chore, a parent reviews it, points move — fought the platform rather than being expressed by it.

The underlying idea was sound and my family was actually using it. The container was wrong.

The approach

Rewritten in January 2026 as a standalone web application: React and TypeScript on the frontend, FastAPI on Python 3.13 with SQLite behind it, packaged as a multi-stage Docker image that builds the frontend and serves it from a small static image alongside the API. Sign-in is local accounts or Google.

That trade meant owning authentication, storage, deployment and updates outright — everything the integration platform had been providing. It has been worth it.

What was actually hard

The users are children, and they use it unsupervised. That changes what testing means. The bugs that hurt are workflow bugs, not function bugs — a claim that silently fails, a reward that can be redeemed twice, a total that disagrees with itself between two screens. Unit tests do not catch those.

So the suite is weighted accordingly: 245 Playwright end-to-end tests walking the real click paths, against 83 backend and 67 frontend unit tests. For this application that ratio is correct, even though it inverts the usual pyramid.

The outcome

Version 0.17.0, in daily family use, installable as a progressive web app so it behaves natively on a phone. It ships an onboarding wizard, email notifications, seasonal themes, allowances and savings goals.

The source is public under GPL-3.0 with a code of conduct, contribution guide and security policy. Publishing it changes how it gets built — every commit is written as though someone will read it, because someone might.