Recruiter Watch
Full-Stack · KI-nativ

Recruiter Watch

Next.jsFastAPIClaude APITypeScript

Hinweis: Recruiter Watch ist ein Portfolio-Projekt, kein Kundenauftrag. Ziel war es, ein KI-Feature zu bauen, das über einen generischen Chatbot-Wrapper hinausgeht — mit einem klar abgegrenzten, praktischen Anwendungsfall.

Die Herausforderung

Viele "KI-Produkte" sind letztlich ein Chat-Fenster vor einem Sprachmodell. Die eigentliche Schwierigkeit liegt woanders: einem Sprachmodell eine verlässlich strukturierte Ausgabe zu entlocken, die sich direkt in einer Benutzeroberfläche darstellen lässt — nicht als Fließtext, sondern als ATS-Score, konkrete Keyword-Lücken und Formulierungsvorschläge.

Der technische Ansatz

Strukturierte Prompts statt freier Konversation. Der Lebenslauf wird zusammen mit einer präzisen Aufgabenbeschreibung an die Claude API geschickt, mit einem klar definierten erwarteten Ausgabeformat. Das reduziert die Varianz der Antworten erheblich im Vergleich zu offenen Chat-Interaktionen.

FastAPI als Backend-Schicht. Die Kommunikation mit der Claude API läuft über ein Python-Backend, nicht direkt aus dem Frontend — das hält den API-Schlüssel serverseitig und erlaubt zusätzliche Validierung und Fehlerbehandlung, bevor eine Antwort den Nutzer erreicht.

Klar abgegrenzter Funktionsumfang. Statt eines allgemeinen "Karriere-Assistenten" liefert das Tool genau drei Dinge: einen ATS-Score, konkrete fehlende Keywords im Vergleich zur Stellenausschreibung, und Formulierungsvorschläge. Diese Eingrenzung macht die Ausgabe vorhersagbarer und den Nutzen sofort erkennbar.

Was das Projekt zeigt

Dass der Wert eines KI-Features nicht aus dem Sprachmodell selbst kommt, sondern aus der Eingrenzung des Problems und der Struktur, die man um das Modell herum baut — Prompt-Design, Backend-Validierung und ein UI, das die Ausgabe sinnvoll darstellt.

Technischer Stack

Next.js, FastAPI, Claude API, TypeScript.

Warum das zählt

Strukturierte statt offene Ausgabe ist das, was aus diesem Feature ein verkaufbares Produkt statt einer Demo macht. Ein Unternehmen kann für einen Score und drei konkrete Keyword-Lücken Geld verlangen; für "einen Chatbot, der manchmal gute Ratschläge gibt", ist das deutlich schwerer.

Ein eng abgegrenzter Funktionsumfang (drei Ausgaben, kein allgemeiner Assistent) macht den Nutzen in den ersten zehn Sekunden klar — das entscheidet meist, ob ein Besucher im kostenlosen Tarif konvertiert, nicht das zehnte hinzugefügte Feature.

Serverseitige Validierung rund um den Modellaufruf hält die Kosten pro Anfrage begrenzt und vorhersagbar — genau das lässt die Unit Economics eines KI-Features tatsächlich funktionieren, statt dass eine ungewöhnliche Eingabe die Marge bei diesem Nutzer sprengt.

Auch hier keine echten Conversion-Daten — das wurde nicht für einen zahlenden Kunden gebaut —, aber das ist die Perspektive, die ich auf jedes KI-Feature anwenden würde, das Geld verdienen soll: Kosten pro Abschluss, Zeit bis zum ersten Nutzenerlebnis, und wie eng das Versprechen bleiben kann, ohne an Nutzen zu verlieren.


Möchtest du ein KI-Feature in dein Produkt integrieren? Lass uns sprechen.