No streaks, no gamification.
I chose user well-being over the metrics-juicing playbook. A broken streak should not punish someone in recovery, and engagement-bait is the wrong incentive in this domain.
Switchback case study
A recovery-support web app built around a single make-or-break moment: someone has an urge, opens the app, and does not relapse.
Solo creator and lead builder: product, architecture, and engineering, in AI-pair collaboration.
The problem
Tracking measures the problem. It does not intervene in it.
The category is full of tracking apps: log your days, watch a streak, get a badge. My bet was that this is the wrong model for the moment that actually matters.
Recovery turns on a specific gap between an urge and an action. Switchback is organized around that gap, not around a dashboard.
Core loop: Awareness -> Interruption -> Replacement -> Reinforcement. Every feature has to serve it or it is noise.
The hard decisions
The product is defined as much by what it refuses as by what it ships.
Deterministic crisis routing, not AI.
The flow that decides whether someone is in crisis is rule-based, not a model call. AI generates supportive content; a deterministic classifier owns the routing.
Three lanes from one account.
Recovery, Mirror, and Ally share one codebase and one account model, with a single mode flag and a mode-aware navigation rail reshaping the app per lane.
Support, not treatment.
Switchback is deliberately scoped as support software that points users toward human connection and professional help, never as therapy or a medical device.
How it is engineered
A real relational product, with clear boundaries between deterministic safety and generative support.
- Stack: Next.js 16, React 19, TypeScript, Tailwind v4, Supabase (Postgres + Auth), Anthropic Claude (Sonnet 4.6), and Vercel.
- Security: Row-Level Security enabled on every one of 37 tables, with policies enforcing that a user can only touch their own rows.
- AI architecture: the Anthropic key never reaches the browser; model calls run from server actions and server components.
- Efficiency: daily reflections are cached per-user-per-day in the database so repeated loads do not re-hit the API.
- Data model: ~37 tables spanning assessments, journaling, interventions, a peer-support Circle, meeting companion, notifications, and referrals.
Outcome and status
Live, early, and real.
Switchback is live in a private alpha with real users: approximately 36 users and approximately 85% activation at last measure. Early-stage alpha, told straight, is more credible than vague scale claims.
Open SwitchbackOptional screenshot slot
Add a signed-out marketing surface or mocked-data product screenshot here after Jack or CC supplies approved imagery.
How it came together
From a daily reflection engine to a real product.
Switchback started as a small project — a reflection engine to ground myself each day. It's since become something I'm genuinely proud of and hope will reach a lot of people. Working part-time, I built the first fully functional alpha live in about five weeks, picking up the infrastructure and AI side quickly as I went and shipping a working product fast.
From there I kept building on the foundation, adding features that reinforce the positive feedback loops at the core of the product. I workshopped the safety guidelines, how user information improves the experience, and how to optimize the site as a whole. Every main feature is something I developed myself through AI-assisted workshops, then refined. Under the hood, a relational database structured across 37 tables runs the back end — the foundation that lets every user's experience stay private, personal, and built to grow with them.
What I took from it
Building Switchback taught me how to drive a full-stack and AI product end to end.
I learned to make the architecture and product calls myself, to use AI tooling as a serious collaborator, and to draw firm lines around the parts of a system where humans, rules, and deterministic behavior need to stay in the loop.