# I Built ResumePilot for a Friend Who Was Tired of Rewriting Their Resume > Source: > Published: 2026-10-04 19:36:10+00:00 Applying for internships is repetitive. You find a job description, compare it with your resume, figure out what matches, notice what is missing, rewrite a few bullets, and then do the same thing again for the next application. A friend of mine was going through exactly that process while applying for internships. So when I saw the Hacktoberfest 2026 DEV Weekend Challenge: Build for a Friend, I decided to build something around that problem. That became ResumePilot. ResumePilot is an AI job-application copilot that compares a resume with a specific job description and turns that comparison into actionable next steps. GitHub: [https://github.com/Srijita33/resumepilot](https://github.com/Srijita33/resumepilot) Demo:[https://drive.google.com/file/d/1B0Xqx0KQHd3hXwqozHce9aMle01oBaIG/view?usp=sharing](https://drive.google.com/file/d/1B0Xqx0KQHd3hXwqozHce9aMle01oBaIG/view?usp=sharing) **The problem** A resume is rarely written for just one job. The difficult part starts after the resume already exists. For every new application, a candidate has to figure out: **What ResumePilot does** The workflow is intentionally straightforward. Upload a resume PDF and provide a job description. ResumePilot then analyzes the relationship between the two and presents: Instead, it tries to answer: "What should I actually understand and improve before applying?" **Start with the application materials** The first screen keeps the workflow focused on the two things that matter: Your resume Upload the PDF containing the experience you already have. The job description Paste the role you are targeting or provide it through the supported file input. The goal was to make the interface feel like a real job-search tool rather than another generic AI dashboard. *From resume and job description to a compatibility analysis* Once both inputs are available, the frontend sends them to the FastAPI backend. The resume PDF is processed using pypdf to extract its text. The application does not write the uploaded resume to disk or store it in a database. The backend then constructs a structured prompt for Gemma 4 containing the extracted resume text, the job description, and rules for how the model should respond. The model is asked to reason about the candidate's existing experience rather than fabricate qualifications. A clearer picture of the candidate's fit **One of the things I deliberately avoided was presenting one unexplained number.** ResumePilot breaks the analysis into several dimensions: Overall compatibility Skills Experience Projects Education It also separates strengths from gaps. In the example above, the system recognizes areas where the candidate already aligns with the role while highlighting requirements that are missing or not strongly represented. The score is explicitly described as an AI-assisted compatibility estimate, not an official ATS score and not a scientifically validated metric. Keyword coverage without blindly stuffing keywords Keyword matching can be useful, but blindly copying words from a job description into a resume isn't the goal. ResumePilot groups relevant job-description terms into categories such as: Matched Missing Needs more context This makes the gaps visible without automatically telling the candidate to add something they have never actually done. That distinction is important. A missing skill should be a signal to investigate, not an invitation to fabricate. Recommendations that explain the "why" A list of missing keywords still leaves the user with the question: "Okay, but what should I actually change?" ResumePilot therefore provides recommendations with an explanation of why the recommendation matters. For example, if a job description specifically asks for SQL optimization but the resume only mentions preparing SQL queries, the system can identify that difference and suggest where the candidate's genuine experience could be expressed more clearly. Recommendations that are not directly supported by the resume can be marked "Verify before adding." The goal is not keyword stuffing. The goal is better communication of existing experience. How does it actually work? This was one of the things I had to understand while building the project myself. ResumePilot is not a RAG system. There is no vector database, no embedding pipeline, and no retrieval stage. It is also not a computer-vision system like YOLO. The architecture is a much more direct LLM application: Resume PDF + Job Description ↓ React + Vite ↓ FastAPI Backend ↓ PDF Text Extraction (pypdf) ↓ Prompt Construction ↓ Gemma 4 via Gemini API ↓ JSON Extraction ↓ Pydantic Validation ↓ Keyword / Score Processing ↓ Results in React The frontend sends the resume and job description to FastAPI. The backend extracts the resume text, constructs the prompt, calls Gemma 4, validates the structured response, performs additional processing, and returns the result to the frontend. So the most accurate description of ResumePilot is: A prompt-based LLM application with deterministic preprocessing and post-processing. **Where Gemma 4 fits** Gemma 4 is the core reasoning component of ResumePilot. For the analysis step, the backend sends Gemma the extracted resume and job description along with instructions such as: The project also has a tailoring path built around the same principle: rewrite, reorder, and emphasize information from the original resume rather than inventing new qualifications. That part is something I would continue refining before calling it production-ready. Why Gemma? The challenge required open-source AI to be central to the project, so I wanted the model itself to be part of the product rather than an optional add-on. I chose Gemma 4 for the core resume and job-description reasoning. For this weekend prototype, I used Gemma through the hosted Gemini API rather than running inference locally. This kept the setup practical without requiring users to download a large model or have a capable GPU. The important distinction is that the application is using Gemma through a hosted API, not local inference. That choice also comes with a privacy trade-off. Privacy is a trade-off, not a marketing claim Resume data can contain personal and professional information, so I wanted to be clear about what the system actually does. ResumePilot does not store uploaded resumes on disk or in a database. However, because the current implementation uses a hosted API, the resume text and job description are sent to the configured API provider for inference. So this is not a fully local privacy-preserving system. I would rather state that clearly than tell users that their data is "completely private" when the architecture doesn't support that claim. What I learned The most useful lesson wasn't how to make an API call to an LLM. It was how much engineering exists around the model. An LLM can produce an answer that looks convincing without necessarily being structurally correct or supported by the input. The application therefore also needs to deal with: A quick look at ResumePilot The demo shows the working flow: Upload resume → add job description → analyze → review compatibility → identify gaps → inspect recommendations The point isn't to tell someone: "You're 78%. Good luck." The point is to explain why the system reached that assessment and what the candidate can realistically look at next. What I would build next This is a weekend prototype, so there are several directions I would take it next. Original vs. tailored resume diff Show exactly what changed between the original and proposed version, along with why. Better editable-resume support Add DOCX support so the workflow fits more naturally into an actual resume-editing process. Self-hosted Gemma The current version uses the hosted API. A future version could support self-hosted Gemma inference for users who want greater control over where their documents are processed. Application history An opt-in local history could make it easier to manage multiple job applications without introducing a centralized database. Why I built it for a friend This challenge wasn't asking me to build the biggest AI system I could. It asked me to build something for one real person. My friend had a repetitive problem: every new internship application meant repeating the same resume-versus-job-description comparison. So I built a small tool around that workflow. It doesn't use RAG. It isn't a multi-agent system. It isn't a computer-vision model. It isn't a research breakthrough. It is a focused application built around a real problem, with Gemma 4 at the core of the reasoning. And that was the point. Not building the biggest system. Building something that is actually useful to someone.