How to build an applicant tracking system with Replit

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

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   Start the app and ask for the database in the same message

   There is no outside database account to create first, so the database is part of your opening message rather than a separate errand. Ask for a notes file too, so the Agent’s conventions carry through the rest of the build.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind, and add a Postgres database to this Repl. Use the one Replit provisions rather than connecting anything outside. Write a short notes file at the project root saying this is an applicant tracking system and fixing the vocabulary for the rest of the build: jobs, candidates, applications, interviews, scorecards, offers. Keep the database connection details in Replit's Secrets rather than in the code.

   The database is already part of the workspace, so asking for it is one message, not a separate signup.

2. 02

   Write the schema, keeping candidates apart from applications

   Ask for the SQL before it runs. The split between a person and their application to a specific role is the part worth reading closely.

   PromptDesign the hiring data modelCopy

   Write the SQL migration for the hiring core, against the Postgres database already in this Repl. Jobs hold 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 reference to their uploaded resume) and a candidate exists independently of any single job. Applications link a candidate to a job, one row per role they apply to, each with its own stage, source, and outcome, so applying twice gives two separate histories. Add job_stages so each job defines its own ordered stages. Show me the SQL before you run it.

   One candidate row, one application row per role. Merging the two is the modelling mistake that surfaces the first time someone reapplies.

3. 03

   Build both halves of sign-in yourself

   Replit’s Postgres is a plain database with no login system wired into it, so the Agent writes both parts: sessions on the server, and a roles table plus a per-job access list the server checks against.

   PromptAdd sign-in, roles, and job accessCopy

   Add email-and-password sign-up, login, logout, and a server-side session for this app, with a profile row per team member. Then two layers of permission, both checked on the server rather than in the browser. A roles table giving each user one of basic, job admin, or site admin, kept in its own table, never on the user record, since anything there is editable by that user. And a job access table naming which users can reach which specific job, so a confidential search stays invisible to everyone not on it. Add a helper the server and the database policies can both call to answer whether a user can reach a given job.

   There is no ready-made login handing the database a user id here, so the server is the thing that knows who is asking. Build that first, and the policies in the next step have something to read.

4. 04

   Scope every row to whoever should reach it

   Replit’s Postgres does row-level security like any Postgres. The difference is where the identity comes from: the server sets who is asking at the start of each request, and the policy reads that.

   PromptAdd row-level security and file rulesCopy

   Turn on row-level security across jobs, candidates, applications, and job_stages. Have the server set the current user's id and role as a session-local setting at the start of every request, then write the policies to read that setting through the job access helper: a site admin reaches everything, a job admin reaches the jobs they are named on plus the candidates and applications attached to them, and a basic user gets that set read-only. Give every insert and update an explicit check naming which job the new row may belong to. Apply the same rule to uploaded resumes: a stored file must not be reachable by anyone who could not read its application. Show me how to prove a job admin gets nothing back for a job they are not on before we move on.

   Read this one closely. It is the step that decides whether a hiring manager can read a search they are not part of.

5. 05

   Bring the careers page and the board online

   The public form and the internal board are what everyone judges this on. Check the preview after each rather than approving both and finding out later.

   PromptBuild the screensCopy

   Build the two screens this system runs on. Publicly: a careers page listing open jobs, and a job page with an application form taking contact details and a resume upload, creating the candidate and the application without requiring an account, working properly at phone width. Internally: a pipeline board per job using that job's own stages as columns, with drag-and-drop and multi-select for moving or rejecting several applications at once, plus a candidate profile showing their details, all their applications, and a timeline.

6. 06
   Destination

   Finish the process, then publish

   Add interviews, scorecards, and offers, walk the whole thing yourself, then publish, checking who the app is visible to before that first release, since Publishing is what sets it.

   PromptAdd interviews, offers, and publishCopy

   Add the last of the process. Interviews: a panel and a time booked against an application, emailing a calendar invite when it is set. Scorecards: the same questions for every interviewer at that stage, with a combined view showing who said what rather than an averaged score. Offers: an approval that clears before anything sends, a generated PDF, and an e-signature request. Then help me test the full flow (post a job, apply through the careers page as an outsider, move the application along, book an interview, submit two disagreeing scorecards, send the offer), and when it holds up, walk me through Publishing: which deployment type fits this, and who the app should be visible to.

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.

All four are Replit’s own hosting rather than a third party. Autoscale or Reserved VM are the two that suit a hiring system with a public careers page in front of it. Scheduled is worth remembering when you build the retention sweep your data decision calls for. Whichever you pick, review what Publishing changes (the domain, who can see the app, the machine resources) before the first release.

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.

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.