How to build an AI resume and cover letter builder with v0

Split it by how many letters you will write. One application, this month, belongs on whatever is fastest, and a chat window is fastest. A job search, a client list, or a room full of students belongs in a builder you own, where the meter is the model’s own price and nobody’s history is kept.

Pick either column and the tool is still yours, and the only meter on it belongs to the model provider. The arithmetic there is small enough to do in your head: at the list price re-read on 8 September 2026, the cheapest current model on the provider’s page, gpt-5.6-luna, charges $0.20 per million input tokens and $1.20 per million output tokens, and a letter sends roughly 1,500 tokens (the resume, the posting, the instructions) and gets roughly 500 back. That is about nine hundredths of a cent per letter, or a thousand letters for about ninety cents. The template’s own default model has left that price list since these pages were first written, so set the model variable to a current one before you count on any figure. Set a monthly spending limit at the provider anyway, because a public function with no cap is a bill you did not decide on.

Prices and rates from developex.com, developers.openai.com, v0.app, v0.app and vercel.com, checked September 2026.

Nothing here takes long. An account, a plan, a GitHub connection you can add when you are ready to deploy, and a key with a spending limit on it before it exists anywhere else. After that, everything is a prompt.

1. 01

   Start the chat and set the rules

   A running project with the form and PDF libraries in it, and three rules stated once that govern everything after: nothing stored, the key only in the route’s environment settings, all AI through that one route.

   PromptSet up the projectCopy

   Start a new project for a resume and cover letter tool. Use Tailwind, a form library with validation, and a library that produces PDF files from text (not from screenshots). Three rules for the whole project, to keep in mind for every later request: nothing about the user is ever stored on a server or in a database, the AI provider key exists only in the deployment’s environment settings and never in any file, and every request to a model goes through one server route we will add later. For now, show me an empty page with the app’s name on it.

   Say the rules once, at the start. They are the claim this whole tool makes, and the easiest thing to break by accident three prompts later.

2. 02

   Two ways in, one text out

   A landing screen with two paths, an upload that reads a file into text, and a guided builder with six sections that add and remove entries without losing anything. Both paths end holding the resume as one piece of text. Fill the builder in with your own history in the preview, because a form that loses an entry when a second job is added looks finished with one job in it.

   PromptBuild the two entry pathsCopy

   Build the first three screens. A landing page with two choices: upload an existing resume, or build one. An upload screen that accepts a plain-text file up to 5 MB, reads it into text in the browser, shows a preview, and refuses any other type with a clear message. And a guided builder with six sections (personal details, experience, education, skills, certifications, languages), each able to add and remove entries, fully validated, keeping its entries when I go back a step. Both paths must end with the resume held as one piece of text in the app’s state, with nothing sent anywhere yet.

   In the preview, add a third job, delete the second, and go back a step. Anything missing is the bug to fix before step 03. Select the section in the preview and adjust the spacing directly if the six sections feel cramped on a phone.

   PromptOptional: accept the files people actually haveCopy

   Extend the upload so it also accepts PDF and Word (.docx) resumes, extracting their text in the browser with a PDF text-extraction library and a .docx-to-text library, with no upload to any server. Show the extracted text in the preview so I can check nothing was lost, and keep the plain-text path working exactly as before.

   Skip this if you will only ever use it yourself. Do it if anyone else will, because the first thing they drop in will be a PDF.

3. 03

   The job, and the one route that writes the letter

   The job form, then the only server-side piece in the whole build: a route in the same project that reads the key from the environment, takes the resume and the job, applies the letter rules, calls the model and returns the letter. The caps go in now, because a route that works is a route anyone can call.

   PromptBuild the job form and the routeCopy

   Add a job details screen with three fields: company, position, and the full job description pasted in, each capped at 5,000 characters with a visible counter. Then add the one server route this app will have. It reads the AI provider key and the model name from environment variables that exist only on the server, accepts the resume text and the three job fields, refuses a resume over 20,000 characters or any field over 5,000, allows at most ten requests a minute from one address, and answers only requests from an origin set in an environment variable. It sends one request to the model with these instructions: write a professional cover letter in proper business letter format with the applicant’s contact details at the top, use the applicant’s real name and background from the resume, highlight the experience that matches the job description, keep a professional but warm tone, and mark the company name and key points in bold using double asterisks. Return only the letter. Wire the form’s button to call the route and show a plain error message if the model does not answer. Tell me exactly which three environment variables to set in the project’s settings, and do not write the key into any file.

   Set the three variables, generate a letter for both real postings, and read them before moving on. The tone rules are the only editorial control you have.

4. 04

   The letter screen, and a draft that survives a refresh

   Where the letter is read, copied and taken away. Two additions earn their place here: a text area so the letter can be edited before it is copied, and a draft kept in the browser so a refresh does not send someone back to an empty builder.

   PromptBuild the letter screenCopy

   Build the result screen. Render the returned letter with the double-asterisk marks shown as bold, a copy-to-clipboard button with a confirmation, a download-as-text button, and an editable version of the letter in a text area so I can change a sentence before copying. Keep the current resume text, job details and letter in the browser’s local storage so a refresh or an accidental back button returns me to where I was, and add a clearly labelled "Clear everything" button that removes all of it. Nothing may be sent to any server as part of this step, and do not add a database for this.

   Refresh the preview mid-flow. Landing back on the start screen with your entries gone means the storage is not wired.

5. 05

   Resume designs, and a PDF a machine can read

   The step this build is judged on. Several designs drawn from the same fields is the visible half. The half that decides whether an application gets read is the export: a PDF built from the resume’s text, with real selectable words in it, rather than a screenshot of the design placed on a page.

   PromptBuild the designs and the exportCopy

   Add a design picker with three resume layouts (a classic single column, a two-column with a sidebar, and a compact modern one) that all render the same resume data from the builder, with a live preview. Then build the export using the PDF library from step 01: generate the PDF from the resume text and layout so the file contains real, selectable text and standard fonts, uses A4 by default with a US Letter option, and breaks cleanly across pages. Do not use a screenshot-to-image approach anywhere in the export. Also add a plain-text download of the resume.

   Download the PDF, open it, and try to select a word. If you cannot, the export is a picture, and a picture is what the shipped template produces. Add designs four to seven later, once the export is right.

6. 06
   Destination

   Guardrails, then deploy

   Two things left, and they decide whether anybody else can use it safely: the route must answer only your published address, and the key must have a ceiling on what it can spend. Then the project deploys to Vercel as one unit, screens and route together, and you test from a phone rather than from the tab that built it.

   PromptLock the route down, then deployCopy

   Review the server route before we deploy. Confirm the allowed-origin check, the input size caps and the per-address request limit all still hold, and add an optional per-day cap on total requests that returns a polite "come back tomorrow" message when it is hit. Confirm the provider key cannot reach the browser by any path, including the build output. Then tell me which environment variables to set in the Vercel project, what to set the allowed origin to once the deployment has its address, and remind me to set a monthly spending limit on the key at the provider. After that, deploy.

   Set the spending limit at the provider before you share the address. Then open the deployment on a phone, generate a letter, and check in the network panel that exactly one request carried the resume and it went to your own route.

Read this project the way somebody cautious about their personal data would. First, list every request the finished page makes over the network, including anything a library loads on its own, and say what each one carries. Second, read the server function and tell me: what it accepts and from where, what stops a stranger calling it in a loop, what happens when the model does not answer, and whether the provider key can reach the browser by any path. Third, confirm nothing about the resume or the letter is written anywhere that survives the tab being closed. For anything that fails, fix it and show me the change.

One rule outranks the rest: the key stays in the function, the resume stays in the tab, and nothing is written anywhere that outlives it. Everything else in this section is detail.

Any of these will serve the pages. Two things to check rather than assume: whether the free tier allows commercial use, since a tool you charge clients for is commercial however small it is, and whether the host can also run your one function, because keeping the pages and the function on one provider is one fewer account to look after.

That is the whole of the server side: one function, wherever you run it. The key goes in that function’s secrets and nowhere else, and the spending limit goes on the key at the provider.

Add a "Rewrite" action under the generated letter with a short text field for an instruction (for example "make it shorter" or "more formal"). Send the current letter, the original resume, the job details and my instruction through the existing ai function, asking for a revised letter that keeps every fact from the resume unchanged. Show the new version next to the previous one with a button to keep either, and add a request-per-minute limit on this action in the function so a rewrite loop cannot run away.

Add a "Match" panel on the job details step. Through the ai function, extract the requirements from the pasted posting as a list, then for each one say whether the resume evidences it, partly evidences it, or does not, quoting the resume line you relied on. Show the three groups in that order, never invent experience, and let me tick the missing ones I genuinely have so the letter can mention them.

Add an optional "Tailor the summary" step after the job details. Send the resume’s summary or opening lines, the posting and the job title through the ai function and ask for two alternative summary paragraphs of at most 40 words each, written for this role and using only facts present in the resume. Let me pick one or keep the original, and use the choice in every resume design and export.

Change the server function’s request to the model without changing what it accepts. Put the letter rules in a system message and the resume and job details in the user message, add a cap on the reply of about 450 words, and add a spelling setting (British or American) read from an environment variable and stated in the rules. Keep the model name in its own environment variable. Then generate letters for my two test postings and show me the old and new versions side by side.

After the letter is generated, add a "Prepare for the interview" action. Through the ai function, produce eight likely interview questions for this posting, and for each one a two-sentence answer outline that uses only experience present in the resume, marking any question the resume gives no material for as "no evidence in resume" rather than inventing an answer. Let me copy the whole list as text.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.