Note: Recruiter Watch is a portfolio project, not client work. The goal was to build an AI feature that goes beyond a generic chatbot wrapper — with a clearly scoped, practical use case.
The challenge
A lot of "AI products" are ultimately a chat window in front of a language model. The real difficulty lies elsewhere: getting reliably structured output from a language model that can be rendered directly in a UI — not as free-form text, but as an ATS score, concrete keyword gaps, and rewrite suggestions.
The technical approach
Structured prompts instead of open conversation. The resume is sent to the Claude API alongside a precise task description, with a clearly defined expected output format. That significantly reduces response variance compared to open-ended chat interactions.
FastAPI as a backend layer. Communication with the Claude API runs through a Python backend rather than directly from the frontend — keeping the API key server-side and allowing for additional validation and error handling before a response reaches the user.
A tightly scoped feature set. Instead of a general "career assistant," the tool delivers exactly three things: an ATS score, concrete missing keywords compared to the job posting, and rewrite suggestions. That scoping makes the output more predictable and the value immediately obvious.
What the project demonstrates
That the value of an AI feature doesn't come from the language model itself, but from how tightly you scope the problem and the structure you build around the model — prompt design, backend validation, and a UI that renders the output meaningfully.
Technical stack
Next.js, FastAPI, Claude API, TypeScript.
Why it matters
Structured, not open-ended, output is what makes this a sellable feature rather than a demo. A business can charge for a score and three concrete keyword gaps; it's much harder to charge for "a chatbot that sometimes gives good advice."
A tightly scoped feature set (three outputs, not a general assistant) makes the value obvious in the first ten seconds — which usually decides whether a free-tier visitor converts, not the tenth feature you bolt on.
Server-side validation around the model call keeps the cost per request bounded and predictable — which is what makes the unit economics of an AI feature actually work, instead of one unusual input blowing up your margin on that user.
No real conversion data here either — this wasn't built for a paying client — but this is the lens I'd apply to any AI feature meant to make money: cost per completion, time-to-first-value, and how narrow the promise can stay while still being useful.
Want to integrate an AI feature into your product? Let's talk.