How I use it
I built this while job hunting, because tracking applications in a notes file stopped working around the tenth one. Every application is a card on a board, and I drag it from applied to phone screen to interview to offer as things move along. The board only lets a card advance one stage at a time and records every change on its own, so I always have an honest history of what happened and when.
The part I lean on most is the assistant. I can type something like 'I applied to the frontend role at X yesterday, and they want a call on Thursday', and instead of editing anything directly, it comes back with the exact changes it intends to make and waits for me to confirm. It can read everything in my pipeline on its own, but it cannot write a single thing without showing me the proposal first.
That assistant runs on a local Ollama model, and every change it proposes goes through the same validation and the same service layer as if I had clicked the buttons myself, scoped to my own data, so it never becomes a back door around the rules the rest of the app follows. The whole thing is mine, runs on my own server, and no recruiter platform ever sees the notes I keep.
Architecture
9
Fastify modules
4 layers
route · controller · service · repo
Local-first
Ollama agent assistant
Confirm
before every write
Stack
Key decisions
- 01
Strict layered backend: routes to controller to service to repository. Repositories only query rows scoped to the authenticated user, services hold the rules and return DTOs, and one global handler maps domain errors to HTTP codes.
- 02
Same-origin SPA and API (nginx in production, Vite proxy in dev), so httpOnly cookie auth works without any CORS workarounds.
- 03
Confirm-before-write assistant: read tools run autonomously inside the agent loop, while write tools come back as proposals. Executing a proposal re-validates the arguments and runs through the same services as the REST API.
- 04
Server-enforced status pipeline: applications move one stage at a time, terminal states have no exits, and every transition auto-writes a status_change activity.