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

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 replit.com, checked September 2026.

Nothing here takes long. An account, a plan, and a key with a spending limit on it before it goes into the workspace’s secrets. After that, everything is a message to the Agent.

1. 01

   Start the workspace 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 Secrets and read only by the route, all AI through that one route.

   PromptSet up the projectCopy

   Start a new web app for a resume and cover letter tool: React with Tailwind on the front, a small server for one route on the back. Add a form library with validation and a library that produces PDF files from text (not from screenshots). Three rules for this 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 this workspace’s Secrets and is read only by the server route, and every request to a model goes through that one route. 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 requests 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. Open the running preview on your phone for this one, because six sections of form is where a small screen breaks first.

   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 to the server yet.

   Add a third job, delete the second, and go back a step. Anything missing is the bug to fix before step 03, because every later step trusts this text.

   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 the 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 on the app’s own server that reads the key from 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 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 this workspace’s Secrets (tell me which two names to create, and do not write either into any file), 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 a third secret. 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.

   Create the secrets, generate a letter for both of your real postings, and read them before moving on. 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. 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 the 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, and that is the first complaint anyone using the shipped template makes.

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 publish

   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 publish as an Autoscale deployment from the same workspace, and test from a phone rather than from the workspace tab.

   PromptLock the route down, then publishCopy

   Review the server route before we publish. 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. Then walk me through publishing this as an Autoscale deployment, tell me what to set the allowed-origin secret to once the published address exists, and remind me to set a monthly spending limit on the key at the provider.

   Set the spending limit at the provider before you share the address. Then open the published address 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.

Every row here is Replit, so you are choosing a shape rather than a vendor, and the shape this build wants is Autoscale. Check who the tool is visible to before the first release, since Publishing is what sets that, and set the route’s allowed origin to the published address in the same sitting.

That is the whole of the server side: one route in the workspace, the key in Secrets, and the spending limit 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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.