AI coaching app · private
Project Kestrel
A mobile coaching app built around six life areas, with an AI coach that proposes changes and waits for your OK.
Project Kestrel is a mobile coaching app that organizes self-improvement around six life areas, with check-ins, goals and community groups. An AI coach sees the same data you do and can propose concrete changes to your plan, but it only acts after you confirm.
Private product
This product isn't public. The name, the mockup screens and the copy are altered, and the case study stays at architecture level.01 / 05 · check-in
Motivation
Most wellness apps track one thing, like steps or food or sleep, and leave you to stitch the picture together. I wanted the opposite starting point. A whole-life check across six areas, where the weakest area becomes the focus for the month.
The AI coach lives inside the product. It reads the same data, uses the same actions as the buttons, and asks before it changes anything. Human coaches get their own workspace, so people stay in the loop too.
Highlights
- A six-area self-check with a radar view and a monthly focus picked from the results.
- Guided goal setting in five steps, up to three goals per area, with small habits under each.
- An AI coach chat that streams replies, reads your own data and asks before it acts.
- Daily check-ins, streaks and community groups.
- A workspace for human coaches and a web console for operators.
Key decisions
One registry for every action
Why
Every user and admin action is declared once, with a permission level and an autonomy level of auto, confirm or never. The UI and the AI coach draw from the same list, so the coach can't do anything the UI can't, and new actions start locked.
What it cost
A declaration proves nothing by itself. Wiring needs its own tests, and some older paths still go around the registry.
Typed contracts first
Why
New endpoints start as schemas shared by the app and the server. The backend is built from typed services, with a tracing span on every method and typed errors instead of exceptions.
What it cost
The learning curve is steep, and older REST routes still live next to the new contracts.
A thin AI layer with an honest mock
Why
Model access goes through a small facade over a mature SDK, with the provider picked by config. Tests and local runs use a mock that labels its own output as mock.
What it cost
With only the mock, the app treats the coach as unavailable, so a fully local demo can't show a conversation.
Split by product area
Why
Each life area and each shared slice, like check-ins or goals, gets its own domain, contract, service and mobile packages. A dependency check fails the build on cycles.
What it cost
That's a lot of packages for a small team, and some exist before they have any content.
Architecture
Every client reaches one service layer, through typed RPC, a streaming edge or older REST routes. Coach actions go through the same registry as the UI, and traces follow a request from the phone to the database.
Limits and what's next
- The AI coach needs a real model provider configured. There's no offline model.
- On the web, members get the phone layout. A desktop layout is future work.
- Part of the API is still legacy REST, kept for compatibility while clients move to the typed contract.
- Some older routes predate the action registry and are being moved onto it.
- Some life areas carried over from an older codebase are still being filled in.