Case study / Personal project
A SvelteKit medication tracking app with one-tap dose logging, live time-since counters, per-medication adherence analytics, and inventory management — built server-first with a dark glassmorphism UI.
Dashboard with quick-log pills, My Day schedule, live time-since counters, and today's dose timeline.
0
Client-side data libraries
All mutations go through SvelteKit form actions — no client-side data fetching or caching library needed.
3
Auth providers
Email/password with verification, Google OAuth, and GitHub OAuth via Arctic.
8
Visual patterns per med
Solid, split, gradient, diagonal stripes, horizontal stripes, polka dots, checkerboard, and radial.
PDF + CSV
Export formats
Full dose history exportable as formatted PDF via PDFKit or raw CSV for spreadsheet analysis.
Medication adherence is hard because existing tools feel clinical, lack fast one-tap logging, don't show live 'time since last dose' counters, and rarely offer honest per-medication adherence analytics. I wanted a server-first app that kept data private and scoped per-user, handled timezone-correct analytics, and delivered a polished dark-mode interface that made daily tracking feel effortless rather than clinical.
01. Built the entire mutation layer around SvelteKit form actions with use:enhance progressive enhancement, so every create, update, and delete goes through the server with no client-side data library. This keeps the trust boundary clear and means the app works without JavaScript for core flows.
02. Implemented live 'time since last dose' counters using Svelte 5 $effect and setInterval on a 60-second tick with visibilitychange recalculation, giving a real-time feel without requiring WebSocket infrastructure.
03. Designed a dual-colour system with 8 visual patterns (solid, split, gradient, diagonal stripes, horizontal stripes, polka dots, checkerboard, radial) so medications are visually distinguishable at a glance — faster recognition than reading labels.
A1. Svelte 5 runes ($props, $state, $derived, $effect) power the client-side reactivity layer, keeping component state predictable and the template syntax minimal.
A2. SvelteKit form actions handle every web mutation through +page.server.ts loaders and actions, with use:enhance providing progressive enhancement so the app degrades gracefully without JavaScript.
A3. Drizzle ORM provides type-safe query building against a Neon serverless PostgreSQL database, with schema definitions that double as the migration source via drizzle-kit.
A4. Lucia v3 manages database-backed sessions validated in hooks.server.ts on every request, with Arctic handling OAuth flows for Google and GitHub providers.
A5. Resend delivers transactional email for verification codes, password resets, and a daily Vercel Cron job at /api/cron/reminders that sends overdue medication alerts.
A6. CSP headers, per-route rate limiting, Zod validation on every form action, and user_id scoping on every database query form the security boundary.
A7. A versioned /api/v1 JSON surface sits beside the form actions, because a native client cannot post SvelteKit form actions. Both surfaces funnel through the same service layer into the same schema, so a dose logged on either is the same row.
A8. A native macOS client (Swift 6, SwiftUI, GRDB/SQLite) consumes that API offline-first: writes land in a local outbox and drain to the server when connectivity allows, with server IDs reconciled back into local rows.
All mutations are form actions with use:enhance progressive enhancement. This eliminates the need for a separate API layer, keeps the trust boundary on the server, and means core functionality works even without client-side JavaScript.
Type-safe schema definitions that generate correct SQL, paired with Neon's serverless driver for fast cold starts on Vercel. Migrations are version-controlled via drizzle-kit.
Database-backed sessions validated in hooks.server.ts on every request, with Google and GitHub OAuth via Arctic. Password hashing uses Argon2, and the registration flow includes a Have I Been Pwned k-anonymity breach check.
Every create, update, and delete operation captures before and after field values as JSONB diffs, providing a complete change history for trust and debuggability.
Colour-coded medication pills on the dashboard allow single-tap dose logging without navigating away from the main view.
Every logged dose shows a live 'time since' counter updated every 60 seconds via $effect, with visibilitychange recalculation when the tab regains focus.
Groups scheduled medications by time-of-day period (morning, afternoon, evening, night) with one-tap logging directly from the schedule.
Each medication gets a primary and optional secondary colour rendered through 8 CSS background patterns for instant visual recognition.
Calculates expected vs actual doses over configurable periods, showing per-medication adherence percentages and consecutive-day streaks.
A GitHub-style contribution heatmap showing dose activity density across the last 90 days, with day-of-week and time-of-day distribution charts.
Full dose history exportable as a formatted PDF report via PDFKit or as raw CSV for spreadsheet analysis and medical appointments.
A macOS client shares the domain rules with the web app but keeps its own local SQLite store, so dose logging works with no connection and reconciles when the network returns. Its sync layer is complete and covered by 406 tests across six Swift packages on the feature branch where it currently lives; the user interface is still in progress.
Every database query filters by user_id on the server side, enforced in hooks.server.ts before any loader or action runs. There is no client-side route that can access another user's data because the scoping happens at the query layer, not the route layer.
All timestamps are stored as UTC in PostgreSQL. Analytics queries use SQL AT TIME ZONE with the user's configured IANA timezone to group doses by local date, while the frontend uses Intl.DateTimeFormat for display — keeping the source of truth in UTC while the experience feels local.
When a user signs in via OAuth with an email that matches an existing email/password account, the system requires email verification before linking. This prevents an attacker from creating a Google account with someone else's email and hijacking their MedTracker account.
A user can create a medication offline and log a dose against it seconds later, before the server has ever assigned that medication an ID. The outbox therefore sends one command per request rather than batching, so the server-assigned ID from the first can be substituted into the second, and the ID rewrite plus the outbox status flip happen in a single local transaction. Porting the domain logic also surfaced timezone bugs in the original TypeScript around DST boundaries; those were deliberately not reproduced, and the divergences are recorded rather than left implicit.
