SQLite via better-sqlite3 with Drizzle ORM migrations
Why: A self-contained container keeps a small household deployment simple and cheap to run.
Tradeoff: Single-node storage — moving to multi-instance hosting would require a networked database.
A private care-coordination platform for household employers and approved care workers. Managers assign and track work; workers see only their own tasks; schedules, proof photos, handoffs, and an audit log keep everyone accountable.
Active development. The public screens below were captured on October 4, 2026. Dashboard capabilities are described from repository evidence, not a production audit. Manager action queues, notification submission status and retry, handover acknowledgment and follow-up ownership, month-end evidence checklists, and an attendance correction are in progress and are not presented here as deployed.
Public screens from CareBoard. Private household dashboards are excluded to protect care and employment information.
A household manager needs to know who is working, what needs doing, what was completed, and what the next shift needs to know. When schedules, task notes, and employer records are spread across messages and paper, reconstructing the day becomes another job. Care workers need clear assignments and a way to share outstanding work without exposing other workers’ private records.
A private household task board with strict role separation. A manager creates, assigns, and completes work and maintains employer records; each worker sees only their own tasks and open work they can claim. Shifts follow a two-week A/B cycle, and proof photos, end-of-shift handoffs, safety reports, and an append-only audit log make accountability routine rather than extra effort.
These points are grounded in the project repository, its tests, and its technical documentation. They are not estimates of business impact.
Workers cannot see other workers' profiles, tasks, reports, or audit data. Disabled workers are blocked on every request, so an existing session cannot retain access. Photos are served only through authenticated, ownership-checked routes.
Profile and task proof photos are retained for a fixed 90-day period and are never exposed as static files.
The repository defines a required verification suite of Node.js tests, lint, and a production build, run before any change is considered complete.
Runs on SQLite in a single container, sized for one household per deployment. Payroll CSVs provide hours, rate, and gross amounts — deductions and net pay remain payroll-software scope, documented in the CSIL readiness matrix.
No verified time savings, adoption figures, or user testimonials are available for this case study. Clearer coordination and less administrative work remain intended benefits.
Manager and worker dashboards covering task assignment, claiming, completion, and proof photos
Evidence: Manager and worker workflows documented in the repository README; private dashboards are not shown in this case study.
Two-week rotating schedules with day-off requests and shift-coverage acceptance
Evidence: Documented in the repository README
Timesheet, payroll, and monthly CSV exports designed to support household employer record keeping
Evidence: Requirements matrix documented in docs/csil-compliance.md
Care-team wellbeing signals and safety incident reporting grounded in published WHO and OECD research
Evidence: Design rationale documented in docs/care-worker-needs.md
Designed so workers see only their own work and data, never other workers'
Design intent; measured impact has not been established.
Why: A self-contained container keeps a small household deployment simple and cheap to run.
Tradeoff: Single-node storage — moving to multi-instance hosting would require a networked database.
Why: Flags long shift runs, short turnarounds, and heavy loads without inferring health or fatigue.
Tradeoff: The signals are workload indicators rather than predictions, and the product copy says so.
Why: Accountability needs a record that cannot be quietly rewritten after the fact.
Tradeoff: Corrections are new entries, so the log grows rather than being edited in place.