Stride

Students keep tasks in one app, their week in a calendar and their focus sessions in a timer. None of them know about each other, so a deadline never learns how much time was planned for it, and a finished session never counts toward the task it was for.

Stride is built around one loop: capture a task, decide what matters now, plan real time for it, work in focused sessions, and adjust tomorrow from what actually happened. The loop only works if every step writes to the same data.

• CaptureQuick Add reads projects, deadlines, priority, estimates, reminders, recurrence and labels straight from the line you type.
• PlanCalendar blocks are stored rows linked to a task, so planned minutes add up against its estimate.
• FocusTimer sessions are saved against the task or block they were started from.
• ProjectsList and board views, sections, members, assignees and comments on the same task model.
• TodayAn optional AI overview summarises the day from what is actually on it.

• Planned time is a row, not a calendar event

  Each block is stored with the task it serves. That lets the app compare planned minutes with the estimate and mark a task unplanned, partly planned, fully planned or overplanned, which is the signal a student actually needs on a Sunday night.

• Clerk for identity, row-level security for access

  Clerk signs people in; its token is passed to Supabase on both the browser and server clients, and 64 Postgres policies decide what each person can read or write, separating their own data from projects shared with them. The database, not the UI, is the boundary.

• Optimistic writes that ignore their own echo

  Edits show instantly, then Realtime brings the same change back from the database. Writes that the client made itself are marked so their echo is skipped, which keeps quick edits from flickering or undoing each other while changes from other tabs and members still arrive.

• The AI summary gets a strict, small input

  The Day Overview route is authenticated, rejects payloads over a size limit, validates every field with a strict schema (task titles, timing, estimates and planned blocks, all capped), calls the model server-side, sanitises the reply and never caches it. The app works fully without it.

• Test the logic people will notice when it’s wrong

  Deadlines, recurrence, reminders, estimates, ordering, filters and the Quick Add parser each have their own tests. Those are the parts where a quiet off-by-one day costs a student a deadline.

• A portfolio MVP, not a production service; the live deployment has been retired.
• Tests cover business logic; browser-level and end-to-end coverage are thin.
• Collaboration exists as foundations (members, assignees, comments, realtime) but was never tested with real teams.
• The schema grew through many migrations and was archived as one baseline, not a clean one-command rebuild.