Personal project · full stack
Job Search Assistant replaces a spreadsheet and a pile of loose documents with a single system: every application with its full status history, analytics that show what actually converts, and the CV and cover-letter documents that go with each one.
The app itself is private, so there is no login screen to show, and everything on this page is built from fictional data. I'm glad to walk you through the app and the repository live.
What this shows
Product decisions, API design, a Go backend, a React UI, CI/CD, hosting and backups. One person, one repository, running in production.
Every architectural choice has a dated entry with the reasoning and the trade-off I accepted. The specs are kept current, so the docs describe the app as it is.
The app has an optional LLM feature. Its output is treated as untrusted: checked in code, and measured against a live model on made-up data before a prompt change ships.
The problem
Before
After
Features
Company, role, source and the full status history with dates. Notes, the pasted vacancy text and a counter of days since the last movement sit on the same card. Drafts stay apart from real applications.
A funnel, median timings, conversion by source and a weekly trend, all computed from the status history. Every figure shows its sample size, so a small n never passes for a fact.
A versioned CV, a cover-letter template with a live preview that highlights what is still unfilled, and a PDF generated on the fly. A letter that was sent is frozen, so the record shows exactly what I submitted.
I'm applying for the Platform Engineer role at Kestrel Cloud. What draws me to the team: your own words.
Sign-in with Google and a single allowed address: nothing is public. The database is backed up every day to Dropbox, with 30 days kept.
Situation, Task, Action, Result: each story is written once and kept in one library, so a good example is never lost in an old document.
Bottom navigation, full-screen dialogs and a table that never needs horizontal scrolling. Even the date input quirk on iOS Safari is handled.
Analytics
How far the applications got.
The real page also splits rejections into before and after an interview, and shows a weekly trend.
Which platform is actually worth the time.
Share of applications that reached an interview. Bars are scaled to the best source.
Applied to first response
6 days
median, n = 48
Between interview rounds
8 days
median, n = 14
Rounds before an offer
3
median, n = 5
Illustrative numbers: the same shape as the app's Analytics page, not my real search. Applications imported from the old spreadsheet are left out of the timings, because their dates are the application date, not the real event date.
How it's built
At runtime
Browser
React SPA
One Go service
Serves the SPA and the API from the same address: no CORS, one URL
PostgreSQL
Serverless Postgres, migrated with goose
Beside the service: Google for sign-in, and an OpenAI-compatible LLM provider for one optional feature (described below), swapped by changing environment variables.
From spec to production
openapi/spec.yaml
The single source of truth for the API.
Code generation
oapi-codegen writes the Go server interfaces, orval writes the typed React Query hooks, sqlc turns SQL files into typed Go. Nothing is written twice.
Pull request, then main
One issue, one branch, one PR. Docs are updated in the same flow.
GitHub Actions
Migrations run on their own when a migration file changes. The deploy is a deliberate button. A daily pg_dump goes to Dropbox, 30 days kept.
LLM integration
The app has one feature that calls an LLM: it can suggest wording for a few fields of a text template, using only my own CV and cases and the vacancy text saved on the card. The app works fully without it, and everything the model returns is checked before I see it.
The CV, my case stories and the vacancy text saved on the card. The form states what leaves the server before I press the button.
Facts about me only from my CV and cases, about the employer only from the vacancy. No source for a fact means no text.
Any OpenAI-compatible API, chosen by environment variables, with a fallback model. Switched off, the rest of the app works as before.
A malformed answer is rejected. Whatever the sources do not back is flagged or dropped, whatever the model claims.
It fills only empty fields, never overwrites what I wrote, and saves nothing by itself. I read every field.
Measured, not assumed
A prompt change is not judged by one good-looking answer. One command runs the real model several times on made-up data and reports, for each of 11 expectations, the share of runs that pass. It also shows where the model is weak, so a limit is known rather than a surprise.
$ make ai-check
Decisions
Go server interfaces and typed React Query hooks are generated from it, so the API and the UI cannot drift apart.
Trade-off Generated code lives in the repository and has to be regenerated whenever the spec changes.
Queries are plain files that become type-safe Go. Every query is explicit and readable, which matters when one person maintains it for years.
Trade-off More SQL to write by hand, and a code generator in the toolchain.
Go serves the built React app and the API from one address, with Postgres on Neon. One service to deploy, monitor and pay for (nothing).
Trade-off Free tiers go to sleep, so the first request after a pause is slow. Fine for a personal tool; the upgrade path is a paid instance, no redesign.
Any OpenAI-compatible API, chosen by environment variables, with a fallback model. Switching provider touches no code.
Trade-off Only the lowest common denominator of the API is used: no provider-specific features.
Migrations run on their own when a migration file changes, so the schema can never lag behind the code. Rolling out is a button, not a side effect of merging.
Trade-off One extra click per release. An automatic "down" migration is deliberately not possible.
Backups are set up before real data goes in, not "someday": a daily pg_dump to Dropbox, with 30 days kept.
Trade-off A restore is a documented manual procedure, not a one-click feature.
Honest edges
Known limits
Next
See it running
There is no recording, and I would rather show the real thing. A short screen-share covers the app in use (the applications table, a status history, the analytics) and then the repository: how it is organised, the API contract, the decision log and the code behind them.