Case study · 2026 · Developer
Resume
ForgeAI
An AI-powered resume platform that helps people turn a rough CV into a professional, ATS-friendly document — with job-specific suggestions instead of generic templates. This page breaks down how the parsing pipeline, the generative AI layer and the data model actually work.
The problem
Most resume tools do one of two things: they hand you a template, or they rewrite your entire document into confident-sounding text that no longer matches your actual experience. Neither helps with the real failure point — an applicant tracking system parsing the file badly, or a recruiter not finding the keywords the role asked for. ResumeForgeAI targets that gap: keep the user's facts, fix the structure, and show exactly where the resume misses the job description.
How it works
01
Parse the source resume
Uploaded resumes are normalised into plain text, then split into logical blocks — contact, summary, experience, education, projects, skills. Python scripting handled the offline parsing and clean-up experiments: stripping layout artefacts, collapsing whitespace, and detecting section headings with simple regex heuristics before anything reaches a model.
02
Structure it with an LLM
Rather than asking the model for prose, each block is sent with a strict schema and the model must reply with JSON only. That makes the output diff-able, storable and renderable. Invalid responses are retried once with the validation error appended to the prompt, which removes almost all malformed output in practice.
03
Score against the job description
When a user pastes a job description, keywords and required skills are extracted and compared with the structured resume. The gap between the two drives a match score plus a concrete list of missing or weakly-evidenced skills — the part users actually act on.
04
Rewrite with intent, not fluff
Suggestions are generated per bullet, never for the whole document at once. Each rewrite is constrained to keep the original fact, add a measurable outcome where one exists in the source, and use an action verb. The user approves each change, so the AI never silently invents experience.
05
Export ATS-friendly
The final render avoids the things applicant tracking systems choke on: tables, multi-column layouts, images, and text inside graphics. Single-column semantic markup, standard section headings, and real text output keep parsers happy.
Technical decisions
Why JSON-only model output?
Free-form text is impossible to store or re-render reliably. A schema turns the LLM into a predictable transformation layer instead of a chat box, and lets the UI treat AI output like any other typed data.
Why per-bullet rewriting?
Whole-document rewrites drift away from the truth and read generically. Scoping each call to one bullet keeps the context small, cheap, and factually anchored to what the user actually wrote.
Why Python alongside a TypeScript app?
Text extraction, heuristics and prompt evaluation are far quicker to iterate on in Python. Scripts were used to build the parsing rules and test prompt variants over sample resumes before the logic shipped into the product.
Why row-level security from day one?
Resumes are personal data. Every table is scoped to the authenticated user at the database level, so an access mistake in the UI cannot leak another person's document.
Stack
Frontend
- React
- TypeScript
- Vite
- Tailwind CSS
- shadcn/ui
Backend & data
- Supabase
- PostgreSQL
- SQL
- Row Level Security
AI & scripting
- Python
- Generative AI (LLM) APIs
- Prompt engineering
- Structured JSON output
What I took from it
The hard part of building with generative AI was not calling a model — it was constraining it. Schema-locked responses, small scoped prompts and a human approval step made the output trustworthy enough to put in front of users. On the full-stack side, designing the database around per-user isolation before writing features kept the privacy story simple as the app grew.