Problem

The app needed to answer simple operational questions reliably: was a turn already logged, which arch changed, when is the next turn due, and what happened last time?

Context / users

This is a focused full-stack utility for a shared household care workflow. It tracks turns, notes, schedule state, and progress.

Solution

I built it as a lightweight client plus a thin backend. The browser handles state and rendering. The API handles login, token verification, settings, turns, and treatment notes.

• Household login flow with JWT session verification
• Turn logging for upper and lower arches
• Support for interval-based and twice-per-week schedules
• Next-due-date and treatment progress calculations
• Treatment notes stored alongside turn history
• Mobile-first interface for quick daily use

Architecture

This is a compact single-view app rather than a routed SPA. The frontend is delivered through one HTML shell with one main JavaScript controller. The backend uses small API handlers and an SPA fallback. Authentication is custom and pragmatic: approved users are defined in environment variables, JWTs are issued by the backend, and the database is accessed server-side with Supabase.

Engineering Details

• • Uses normalized relational tables for settings, turns, and treatment notes instead of storing everything in one blob
• • Implements custom JWT auth with backend verification
• • Loads settings, turns, and notes in parallel to reduce wait time after login
• • Escapes user-provided note content before rendering it back into the DOM
• • Uses a shared-household access model so multiple approved users can work against one record

Outcome

• Produced a usable full-stack treatment tracker for a real household workflow
• Turned a repetitive care task into a clearer, lower-friction process
• Created a portfolio project that demonstrates practical full-stack product thinking

Tradeoffs / Limits

• • The frontend is intentionally simple, but most client logic lives in one main JavaScript file
• • The shared-household model is pragmatic, not a generalized multi-user architecture
• • There is no visible automated test suite in the repo
• • The current repo appears to contain a settings-save bug that should be fixed before presenting it as polished

Why It Matters

It shows how I approach small real-world software problems: model the data carefully, choose a right-sized architecture, and solve the workflow without adding unnecessary complexity.