Skip to main content
Back to projects
Active
Founder and sole developer

CareBoard

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.

Real product screens

Public screens from CareBoard. Private household dashboards are excluded to protect care and employment information.

CareBoard public homepage with a clearly labelled example task board showing done, in-progress, and open tasks
Public product homepage. The example board is part of the real site; it is illustrative, not a capture of a private household dashboard.
CareBoard sign-in page with empty email and password fields and approved care-team access guidance
Public sign-in screen. Manager-approved access is explained before sign-in. No private care data or credentials are shown.

The problem

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.

The approach

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.

Evidence in the implementation

These points are grounded in the project repository, its tests, and its technical documentation. They are not estimates of business impact.

Security and role isolation

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.

Privacy by default

Profile and task proof photos are retained for a fixed 90-day period and are never exposed as static files.

Testing

The repository defines a required verification suite of Node.js tests, lint, and a production build, run before any change is considered complete.

Known constraint

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.

Implemented capabilities and intended benefits

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.

Technical choices and tradeoffs

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.

Wellbeing signals derived only from schedule and task data

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.

Append-only audit log for task history

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.

Technical foundation

  • Next.js 16 (App Router)
  • React 19
  • TypeScript
  • Tailwind CSS 4
  • shadcn/ui
  • SQLite (better-sqlite3)
  • Drizzle ORM
  • Auth.js (NextAuth v5)
  • PWA (manifest + service worker)
  • Docker
  • Coolify