How to build an applicant tracking system with OpenAI Codex

Rule of thumb: if you hire continuously and your process has opinions (your own stages, your own scorecard questions, an approval chain that matches your org), building your own pays back quickly against a mid-tier subscription you would be on for years. If you hire two people a year, or you need job-board distribution and compliance reporting on day one without touching a codebase, buy. The awkward middle is a growing team on a free or entry tier that is about to need scorecards and signed offers, because that is the upgrade that changes the number.

* The free Supabase tier is sized for building, not for hiring on: 500 MB of database, 2 active projects, and a pause after a week of no activity, which for a careers page means an applicant arriving at a dead link. Resumes count against storage too. The Pro plan, from $25/mo, keeps it awake.

Either column leaves you owning the system outright, so the tenth interviewer and the eleventh open role both cost nothing to add. What neither column carries is the fee every hosted system in the table above runs on: a price per seat, or per job slot, or per hire, charged for as long as you keep hiring. Yours has none of those, and the only bill that moves after launch is the database and the host.

Prices and rates from supabase.com, developex.com and learn.chatgpt.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   Write AGENTS.md before anything is scaffolded

   Codex reads AGENTS.md at the start of every task, so writing it first means the conventions are loaded before there is any code to be inconsistent with. The scaffold comes second, in the same task.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind, and the Supabase JS client, and this project is an applicant tracking system, so note the vocabulary you should keep consistent (jobs, candidates, applications, interviews, scorecards, offers) and any conventions you want held to. You load that file automatically at the start of every later task, so nothing in it needs repeating by hand. Then scaffold the project itself: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots before you stop.

   Writing AGENTS.md first is what stops task four from inventing its own name for what task two already called an application.

2. 02

   Get the candidate-versus-application split right

   Have Codex write the migrations for the part everyone models wrong the first time: a person exists once, and each role they apply to is a separate application with its own stage. Ask to see the SQL before it runs.

   PromptDesign the hiring data modelCopy

   Write the Supabase migrations for the core of a hiring system. Jobs carry a title, department, location, employment type, description, and a status through draft, open, on hold, and closed. Candidates are the people (one row each, holding name, contact details, and a resume file in Storage) and they exist independently of any particular role. Applications sit between the two, one per candidate per job, carrying that application's own stage, source, and eventual outcome, so somebody applying to two openings ends up with two separate histories rather than one that overwrites itself. Add a job_stages table too, so each job defines its own ordered stages instead of every role sharing one list. Print the SQL for me before it runs, and regenerate the TypeScript types once it is applied.

   Per-job stages are cheap now and expensive later. Every screen that reads a stage has to change if you add them after the fact.

3. 03

   Narrow permissions, then wire up sign-in and job access

   This task touches authentication, which is exactly the kind of change worth scoping Codex down for rather than leaving the wider settings you would use for routine edits.

   PromptAdd auth, roles, and job accessCopy

   This task touches authentication, so narrow your permissions to just this one rather than keeping whatever you had set for routine edits. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session, a profiles row per user, and a useUser hook. Then build the permission model in two layers. First, an app_role enum of 'basic', 'job_admin', and 'site_admin' with a user_roles table linking a user_id to a role, kept in its own table rather than on the account, since anything stored on the account is editable by the person it belongs to, plus a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) that reads it without recursing. Second, a job_acl table listing which users can reach which specific job, and can_access_job(_user_id uuid, _job_id uuid), also SECURITY DEFINER, returning true for a site_admin or for anyone named on that job. One migration, and walk me through the diff before it runs.

   A role says what kind of user someone is. The access list says which searches they are on, and only the second one can hide a confidential role.

4. 04

   Read this diff properly: it is the one that protects candidates

   Row-level security across every table, and matching rules on the resume files. Of every diff in this build, this is the one to actually read rather than approve on trust.

   PromptAdd row-level security and storage rulesCopy

   Turn on row-level security across jobs, candidates, applications, and job_stages, and write the policies through can_access_job. A site_admin reaches every row. A job_admin reaches the jobs they are named on, plus the candidates and applications attached to those jobs, with write access. A basic user sees the same set read-only. Give every insert and update its own WITH CHECK clause naming exactly which job the new row is allowed to belong to, so nobody can file an application against a search they cannot see. Then carry the same rule into Storage: the resumes bucket must not be public, and fetching a file has to fail for anyone who could not read the application it belongs to. Once it is applied, walk me through proving all of it: a job_admin querying a job they are not on should come back empty, and a resume URL from that job should refuse to download.

   Table policies and storage policies are written separately, so it is entirely possible to secure one and leave the other wide open.

5. 05

   Point Codex at the screens, a few files at a time

   The public careers page and the internal board are the two surfaces this system is judged on. Codex only needs the files each screen actually touches, not the whole project.

   PromptBuild the screensCopy

   Now the screens, on top of what is already there. Publicly: a careers page listing open jobs, and a job page with an application form that takes a resume upload and creates the candidate and the application without asking anyone to register. Internally: a pipeline board per job using that job's own stages as columns, with drag-and-drop between them and bulk select for moving or rejecting several applications at once. And a candidate profile pulling together their details, every application they have open, and a timeline of what has happened on each. Keep the data access in typed hooks rather than spread through the components.

6. 06
   Destination

   Finish the loop to a signed offer, then verify it yourself

   Interviews, scorecards, and offers close the process. This is a long, well-scoped piece of work, a reasonable one to hand to a cloud run while you do something else, provided you read the diff before it merges.

   PromptAdd interviews, offers, and testCopy

   Add the last three pieces. Interviews: a table linking an application to a panel of interviewers, a time, and a stage, sending a calendar invite by email when one is booked. Scorecards: one submission per interviewer against a shared set of questions for that stage, with a combined view on the application that shows who said what rather than an average. Offers: an approval chain that has to clear before anything sends, a generated PDF, and an e-signature request against it. When that is in, run the app and take it end to end yourself (post a job, apply through the careers page as an outsider would, move the application along the board, book an interview, submit two scorecards that disagree, then send an offer), then fix whatever does not hold up.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

The one rule that matters: never put a secret key (database, e-signature, mail, or AI) in the app or a public repo. If one ever leaks, reset it right away.

Any of these will serve the app. The thing to check before you settle is not the price but the licence: a free tier is not automatically free for business use, and Vercel’s Hobby tier is explicit that it is for personal projects only. An internal hiring tool is company use however few people log in, so read the plan terms for whichever host you pick.

Add a server-side function that takes an uploaded resume, sends its text to your ai function, and returns structured fields (name, contact details, work history with dates, education, and skills) then pre-fills the candidate profile with them and shows the recruiter what was extracted before saving.

Add a "Summary" panel on the application view that sends the job description and the candidate’s parsed profile to your ai function and returns a short summary of where they line up and where they do not, quoting the evidence for each point. Present it as a note for the reviewer, never as a score or a recommendation to reject.

Add a "Suggest questions" action on the interview screen that sends the job description, the interview stage, and the candidate’s profile to your ai function and returns a handful of specific questions the interviewer can edit before the call.

Add a "Panel summary" block on the candidate page that sends every submitted scorecard for that application to your ai function and returns a short summary of consensus and disagreement, listing which interviewer said what rather than averaging them into one verdict.

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.