Therapist Practice Platform

The problem

Therapists running a private practice stitch together separate tools to do one job — a scheduler, a client-records system, a notes app, and billing that doesn’t talk to any of them. I picked that as the domain for a practice project: build one place that does all of it.

Current state

This is a personal, stealth build — not a startup, not headed to market. I’m using it to sharpen Claude Code, Claude Skills, and agent-orchestration craft, and to build out a portfolio of real, working systems. It’s a working prototype on Next.js, Prisma and Postgres: scheduling, client management, session notes, intake and consent forms, and billing. It hasn’t shipped and isn’t in front of real therapists yet — this is early, and I’m building it the way I build everything else: solo, AI-assisted, in the open.

Decisions worth noting

• No AI in the product; all of it in the process. There is no model call anywhere in the codebase — a therapist’s records are not a place to experiment. Claude Code wrote most of the implementation. The data model, the module boundaries and the privacy layer are mine, and they are the part I would defend in a review.
• Designed before built. Twelve modules were specified up front — workspace and access, client records, migration and a soft transition off spreadsheets, forms, session notes, scheduling, payments and policies, notifications, and an ethics-and-privacy layer — before the first screen existed. That is the system-design discipline from the Scaler M.S. applied to a real domain, and it is why the codebase has stayed navigable past four thousand commits.

My role

Solo build, own IP, in progress as of 2026 — a practice project, not a product launch. I’m writing about the build as it happens — more at /writing.