How to build an applicant tracking system with Claude Code

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 claude.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 Claude Code runs the commands.

1. 01

   Set up the project

   Get an empty app running against your own database, and hand Claude Code a notes file so it stops guessing at your conventions halfway through. One prompt covers all of it.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and the conventions for an applicant tracking system (jobs, candidates, applications, interviews, offers), so later edits stay consistent with the first ones.

   Gives Claude Code a project and a memory to work against.

2. 02

   Separate the candidate from the application

   The one modelling decision that costs a rewrite if you get it wrong. Someone who applies to two roles is one person with two applications, each at its own stage.

   PromptDesign the hiring data modelCopy

   Create the core data model as Supabase migrations. A jobs table (title, department, location, employment type, description, and a status covering draft, open, on hold, and closed). A candidates table for the person (name, contact details, and their resume file in Storage) with exactly one row per person. An applications table joining a candidate to a job, carrying its own stage, source, and outcome, so the same candidate can apply to several roles independently. And a job_stages table so each job can define its own ordered stage list rather than sharing one global set. Write the migration SQL, let me review it, apply it, then regenerate the TypeScript types.

   One candidate row, one application row per role they apply to. Merging those two is the mistake that surfaces the first time somebody reapplies.

3. 03

   Add team sign-in and the per-job access list

   Your colleagues need accounts, and each job needs its own list of who can open it. Roles alone are too blunt for a confidential search.

   PromptAdd auth, roles, and job accessCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a profiles row per user, and a useUser hook. Then create an app_role enum with 'basic', 'job_admin', and 'site_admin', and a user_roles table linking a user_id to a role, kept out of the user's own metadata so nobody can promote themselves. Add a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) that reads user_roles without recursing. On top of that, add a job_acl table granting a specific user access to a specific job, and a second SECURITY DEFINER function can_access_job(_user_id uuid, _job_id uuid) that returns true for a site_admin or for anyone listed on that job. Put it all in one migration.

   Two layers on purpose: the role says what kind of user you are, the access list says which searches you are actually on.

4. 04

   Lock the tables down before a real resume lands in one

   This is the step where a hiring system either protects candidate data or quietly does not. Read what comes back rather than skimming it, and remember the resume files need rules of their own.

   PromptAdd row-level security and storage rulesCopy

   Enable row-level security on jobs, candidates, applications, and job_stages, and write the policies against can_access_job: a site_admin reaches everything. A job_admin reaches the jobs they are listed on and every candidate and application attached to those jobs. A basic user reaches the same rows read-only. Name the WITH CHECK clause explicitly on every insert and update so nobody can attach a record to a job they cannot access. Then do the same for Storage: the resumes bucket must not be public, and its access policy has to match the application's: if you cannot see the application, you cannot fetch the file. Put it all in a migration, then show me how to verify that a job_admin on one job gets nothing back when they query another job's candidates, and that a resume URL from that other job fails to download.

   Locking the tables and leaving the resume bucket public is the version of this that looks finished and is not.

5. 05

   Build the careers page and the pipeline board

   Now the two screens that carry the product: the public one strangers use to apply, and the internal one your team lives in all day.

   PromptBuild the screensCopy

   Build the core screens against these tables. A public careers page listing open jobs and a detail page with an application form that accepts a resume upload and creates a candidate and an application without requiring an account. An internal pipeline board per job, with the job's own stages as columns, drag-and-drop to move an application between them, and bulk select for moving or rejecting several at once. A candidate profile showing the parsed details, every application that person has, and a timeline of what happened. Keep all data access in typed hooks.

6. 06
   Destination

   Add interviews, scorecards, and offers, then walk it end to end

   Finish the loop from applied to signed, then apply for one of your own jobs as a stranger would and fix whatever that turns up.

   PromptAdd interviews, offers, and testCopy

   Add an interviews table (an application, a panel of interviewers, a time, and a stage) that emails a calendar invite when one is scheduled, and a scorecards table holding one submission per interviewer against the same set of questions, with a combined view on the application. Then add offers: an approval chain that has to clear before the offer sends, a generated PDF, and an e-signature request. Once that is in, run the app and walk me through the whole flow (post a job, apply through the careers page as an outsider, move the application through the board, schedule an interview, submit two scorecards, and send an offer), then fix anything that breaks on the way.

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 picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.