How to build an AI resume and cover letter builder with OpenAI Codex

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 and learn.chatgpt.com, checked September 2026.

Nothing here is worth memorizing. The first three just need to exist on your machine, the key needs a spending limit before it exists anywhere else, and the documents are files you already have. From step 01 on, you hand Codex a task and it runs the commands.

1. 01

   Get the project running

   An empty app on your machine with the form and PDF libraries already in, and a short notes file carrying the three rules of this build, which Codex reads at the start of every task.

   PromptSet up the projectCopy

   Scaffold a new React 18 + Vite + TypeScript project and add Tailwind, a form library with validation, and a library that produces PDF files from text (not from screenshots). Add an empty serverless function folder for the one server piece this app will have. Create an AGENTS.md with three rules: nothing about the user is ever stored on a server or in a database, the AI provider key exists only in the server function’s secrets and never in the browser bundle, and every request to a model goes through that one function. Start the dev server and confirm a blank page renders.

   The notes file is how the rules survive between tasks. Codex reads it before each one, which is exactly when a rule is most likely to be broken by accident.

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. Test the builder with your real history, 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

   Task: 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. 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 end with the resume held as one piece of text in app state, with nothing sent anywhere. Run the app and report what you tested.

   Then do the test yourself: fill in your own history, add a third job, delete the second, go back a step. Anything missing is the bug to fix before step 03.

   PromptOptional: accept the files people actually haveCopy

   Task: extend the upload to accept PDF and Word (.docx) resumes as well, extracting the 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 unchanged.

   Skip it for a tool only you will use. Do it for anyone else, because the first thing they will drop in is a PDF.

3. 03

   The job, and the one function that writes the letter

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

   PromptBuild the job form and the functionCopy

   Task: 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 write the one serverless function this app will have. It reads the AI provider key and the model name from server-only environment variables, accepts a JSON body with 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 with double asterisks. Return only the letter. Wire the form to call the function and show a plain error if the model does not answer. Show me how to set the three variables locally without the key entering any file the browser bundle is built from, then run the function against the resume and posting in the test folder and paste me the letter.

   Read the letter before moving on, then run it against the second posting. The tone rules are the only editorial control you have, and this is the cheapest moment to change them.

4. 04

   The letter screen, and a draft that survives a refresh

   Where the letter is read, copied and taken away. The template stops at copy and download. Two additions earn their place: a text area so the letter can be edited before copying, and a draft kept in the browser so a refresh does not empty the builder.

   PromptBuild the letter screenCopy

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

   Refresh 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

   Task: 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, with a live preview. Build the export with the PDF library from step 01, generating the file from the resume text and layout so it contains real selectable text and standard fonts, uses A4 by default with a US Letter option, and breaks cleanly across pages. Do not use any screenshot-to-image approach. Add a plain-text download too. Then open the generated PDF, search it for a word from the test resume, and report whether the search found it.

   If the search finds nothing, the export is a picture, which is what the shipped template produces. Add designs four to seven later, once the export is right.

6. 06
   Destination

   Guardrails, then publish

   Two things left: the function must answer only your published address, and the key must have a ceiling on what it can spend. Then the pages go to a static host and the function to a functions service, and you test from a phone rather than from the machine that built it.

   PromptLock the function downCopy

   Task: review the server function before release. Confirm the allowed-origin check, the input size caps and the per-address limit still hold, add an optional per-day cap on total requests with a polite "come back tomorrow" message, and confirm the provider key cannot reach the browser by any path, including the build output. Then walk me through setting a monthly spending limit on the key at the provider’s dashboard, and tell me what to set the allowed origin to once I have a real domain.

   Set the spending limit at the provider before the address exists anywhere public. It is the one protection here that is not code.

   PromptPublish itCopy

   Task: build the pages for release and walk me through deploying them to a static host, including the rewrite rule a client-side route needs so a link to the job step does not 404. Deploy the function to a functions service with its three environment variables set there, set the allowed origin to the published domain, and point the pages at the function’s address. Then list what I should check on the published address rather than locally: a letter generated from a phone, the network panel showing exactly one request carrying the resume and going to my function, and the exported PDF still containing selectable text.

   The network panel check on the live address is the whole privacy promise of this tool, and it takes about a minute.

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.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.