Coach Mark
self-improvement
as an RPG.

The challenge.

Habit apps are good at counting and bad at coaching. They can tell you the streak broke; they can't tell you why, or what to do on the day you have four hours of energy instead of one. The interesting problem isn't tracking — it's turning "I want to get in shape / focus better / write more" into something small enough to do today, and then adjusting it once real life provides evidence.

That's a loop, not a checkbox:

• Say what you want to improve. In your own words, not a template.
• Get a plan small enough to start. Built from the goal plus recent check-ins, not from the goal alone.
• Do today's tasks and record how it went. Including the bad days — those carry the most signal.
• Get a next move that accounts for the history. The part every streak counter skips.

The approach.

Make the model the coach, not the copy

The AI isn't decoration bolted to a tracker. GPT-4o does the load-bearing work: breaking a goal into quests, generating the day's tasks, running onboarding, handling reflection, and driving the conversational coach. The coach reads the user's six character stats and current lifestyle debuffs before recommending anything, so the advice moves toward whatever is actually out of balance.

Borrow the RPG, not the gimmick

Gamification usually means confetti. Here the game layer is the data model: six stats — Focus, Energy, Resilience, Intellect, Creativity and Recovery — that a Skyrim-style skill tree reads from. Per-stat progress is derived from the tasks you actually completed rather than stored as a number the app can inflate. A skill tree makes "what should I do next" legible in a way a streak number never does.

Give it its own room in a shared house

Coach Mark shares one Supabase project with the rest of the PickBits estate, which is a standing invitation for two products to collide in the public schema. It doesn't, because every table is namespaced. From the schema source:

"CoachMark lives in its own coachmark schema (folded into the shared PickBits Supabase project). All tables are namespaced here so they never collide with other PickBits products' public tables and can be cleanly un-merged later."

That last clause is the point. A shared database is a cost decision, and cost decisions should stay reversible.

Rebuild in place, without breaking the people using it

Coach Mark is mid-rebuild of its core loop, under a written contract that treats production data as immutable until a forward migration and a rollback plan are reviewed — no deleting an old table, column, endpoint or screen until its replacement passes the acceptance tests. The destructive migration has a runbook: back up the schema, declare a maintenance window, keep every step idempotent, smoke-test production after. There's a rehearse script that runs the migration against a genuinely fresh database, because a migration that only works on your database is a migration you haven't tested.

The stack.

Three managed services, each doing one job:

The Vite SPA deploys to Vercel; the Express API runs on Railway from a Dockerfile with a health check; Supabase holds Postgres and Auth. Auth is stateless by design — the client sends a Supabase bearer token, the server verifies it, and there are no server-side sessions to expire, replicate, or leak.

The results.

In alpha and open for sign-ups. The numbers below describe the build, because they're the ones we can stand behind — Coach Mark is early, and we're not going to invent a user count to decorate a page.

What it looks like.

What the work looks like.

Coach Mark is a PickBits product, which means it's also the proving ground — the patterns taught in the University tracks get used here first, on something with real users and a real bill. If you want the same operator-led delivery pointed at your build, scope it on a free 30-minute call.