Technical Overview

Proof for the boring parts that matter.

This page covers auth, request hardening, operational safeguards, architecture discipline, and release confidence rather than feature marketing.

It focuses on the behind-the-scenes implementation details that matter in production: what is protected, how failures are handled, and where the code can be inspected.

View Repository Try Signup Flow Open Demo App

Implementation Areas

Implementation details behind the product surface

These sections summarize the behind-the-scenes work and point directly to the relevant repo files.

Identity

Auth and session model

Account lifecycle work is treated as core product behavior, not as a single happy-path sign-in form.

Auth.js credentials auth uses JWT sessions carrying user ID, verification state, and session version.
proxy.ts protects /app/* and redirects both unauthenticated and unverified users before dashboard routes render.
Email verification, password reset, change email, change password, and scheduled delete/restore flows each have dedicated handling.
Passwords use Argon2id; auth tokens are 32-byte random values stored only as HMAC-SHA-256 hashes with single-use expiry semantics.

Inspect In Repo

Auth config Token handling Route protection Auth tests

Traffic Hardening

Public abuse prevention

The public-facing parts of the app are intentionally hardened because this demo is meant to be safe to expose.

Boundary validation uses Zod for auth forms, dashboard input, and query parameters before writes happen.
Signup integrates Cloudflare Turnstile, with explicit production policy, misconfiguration warnings, and fail-closed verification behavior.
Shared limiter definitions cover auth flows, dashboard writes, exports, consent audit routes, and the public liveness endpoint.
Blocked or unavailable limiter decisions are logged as structured auth events without leaking request secrets.

Inspect In Repo

Auth validation Rate limit policy Auth rate-limit enforcement Turnstile policy

Structure

Architecture and service boundaries

The codebase is organized so the boring parts stay inspectable instead of being hidden behind page-level glue.

App Router defaults to server-side rendering and only opts into client components where interactivity is actually required.
API handlers and server actions stay thin: validate, authorize, call service helpers, then return safe results.
Business logic lives under src/lib so auth, consent, dashboard data, and deployment checks are testable outside page components.
The data model is intentionally per-user, which keeps authorization and query scoping explicit instead of faking multi-tenancy.

Inspect In Repo

Architecture overview ADRs Dashboard actions Item service

Data Discipline

Data boundaries and auditability

Guest mode, authenticated persistence, and consent evidence all follow different rules on purpose and those boundaries are explicit in code.

Guest mode mutates cloned in-memory data only, so public demo traffic never writes business records and refresh resets state.
Authenticated reads and writes are scoped by userId, with service-layer checks before returning or mutating records.
Consent capture uses signed replay tokens, a browser retry queue, consent-context matching, and idempotent server persistence.
Dashboard mutations pair writes with activity logging and path revalidation so operational behavior is inspectable after changes.

Inspect In Repo

Guest demo route Consent replay route Consent retry queue Dashboard data queries

Runtime Safety

Operational safety

The deployment story is designed to be explicit about what must be configured, what can fall back, and what should fail hard.

Deploy-time validation checks critical secrets, email provider rules, Turnstile config, Upstash config, and readiness protection before live environments boot.
Readiness is bearer-token protected and reports degraded status if database or app URL checks fail; liveness is uncached and rate-limited.
Preview and production are treated differently on purpose so reviewers can see where fallbacks are allowed and where the app must be strict.
Node and pnpm versions are pinned, and CI runs Prisma generate plus migrations before checks to reduce environment drift.

Inspect In Repo

Deploy env validation Health report Readiness route Package/runtime config

Verification

Test and release discipline

Testing, CI, and release checks are treated as part of the implementation, not as an afterthought.

Vitest covers auth, consent, rate limiting, deployment config, dashboard queries, and other pure or server-side paths.
Playwright covers auth core flow, demo behavior, theme correctness, legal pages, cookie consent, and marketing routes.
GitHub Actions split fast CI, end-to-end, and visual regression into separate workflows so failures are easier to isolate.
Architecture docs, ADRs, and the reviewer guide live alongside the code so technical decisions stay close to implementation.

Inspect In Repo

Reviewer guide CI workflow E2E workflow Visual workflow

Next step

Validate the product surface

After reviewing the implementation, test the public flows directly in the demo and signup experience.

Open Demo App Try Signup Flow