How to build an applicant tracking system with v0
Use v0 (Vercel’s AI UI generator) to convert plain-text prompts into production-ready React & Next.js screens, from pipeline boards to scorecards. Then, attach a database and API routes to process live applications.
v0
$ Build the screens for an applicant tracking system (a careers page with an application form, a pipeline board with stage columns, a candidate profile, and a scorecard), then connect a database and write the routes that make them save real applications.
- Screens generated first
- Database and routes added next
- Ready to preview
What an applicant tracking system actually is
An applicant tracking system is the single place a role lives from the day it opens to the day someone signs: every applicant, every interview note, every decision, and who is allowed to see which of them.
Without one, a role is scattered across an inbox, a shared drive of resumes, and a spreadsheet somebody renames every Friday. Two people interview the same candidate and neither reads the other’s notes. A promising applicant goes three weeks without a reply because nobody owned the reply. An ATS pulls all of it into one record per candidate that the whole hiring team works from.
Two things make this genuinely hard, and neither is the screens. One is the permission model, where a hiring manager should see their own roles and not the compensation discussion on someone else’s. The other is that a candidate is not the same thing as an application, because one person can apply to three roles and be at a different stage in each. Get those two right and the rest of the system is mostly forms and lists on top.
One record, many readers
A recruiter, a hiring manager, and three interviewers all touch the same candidate. They need different views of it, and different permission to change it, without anyone keeping a private copy in their own notes.
A candidate is not an application
The person exists once. Their application to a specific role exists per role, with its own stage, its own scorecards, and its own outcome. Modelling those as one table is the mistake that costs a rewrite later.
Access is per job, not just per role
Job title is too blunt a permission. A hiring manager for one opening has no business reading the pipeline for a role in another department, and confidential searches need to be invisible rather than merely uninteresting.
What a bad process costs
~$4,700
is the average cost of a single hire, per SHRM’s benchmarking data as published in 2022, money that is spent whether or not the process that spent it was organised.
SHRM, 2022 (The Real Costs of Recruitment) · checked August 2026
The parts every applicant tracking system is built from
Before you build, it helps to know the pieces. Almost every ATS comes down to these six, and each one is something you can ask your AI coding tool to build or extend in plain words.
Roles, candidates, and applications
A job opening, a person, and that person’s application to that opening: three separate things that get confused constantly. Model them separately and someone can apply to two roles without their history in one overwriting the other.
A pipeline everyone reads the same way
Named stages a candidate moves through, with the move recorded rather than implied. When someone asks why a candidate is still in screening, the answer is on the record instead of in somebody’s memory.
A public way to apply
A careers page listing open roles and a form that takes an application without an account. This is the one part of the system strangers touch, so it has to work on a phone and it has to not lose a file.
Interviews and structured scorecards
Scheduling that produces a real calendar invite, and the same set of questions for every interviewer on a panel. Structured feedback is what makes two interviewers comparable rather than two opinions.
Offers, approvals, and a signature
An offer usually needs someone else to approve it before it goes out, then arrives as a document the candidate signs. Both halves belong in the system, or they end up back in email.
Reporting that answers “where is this role?”
How many candidates sit at each stage, how long they have been there, and where people drop out. Without it, a stalled search looks exactly like a healthy one until someone asks.
Own your hiring system or rent it every month
Most teams reach for a hosted ATS, then discover the tier with scorecards is two steps above the price they were quoted. Owning the system changes that arithmetic. Here is the trade-off, side by side.
Build your own
Your own hiring system is a one-time build shaped around the process your team already uses, and with an AI coding tool writing the plumbing, that build is days rather than a quarter.
- Pay to build it once, then only your own infra bills: no monthly subscription that grows with headcount
- Stages, scorecard questions, and approval chains that match how you actually hire
- Add every colleague as a user without moving up a tier to do it
- Candidate data sits in a database you control, which matters more here than in most tools
- Add your own AI on the model you pick: resume parsing, screening summaries, interview questions
- Full ownership of the code and data: export anytime, zero lock-in
Buy a hosted ATS
Workable · Greenhouse · Ashby · Breezy HRA hosted ATS is running this afternoon and someone else keeps it up. The costs are that the features you want are often gated a tier or two above the advertised price, and the process is theirs to define.
- Live in minutes: sign up and start, nothing to build or host
- Job-board distribution, sourcing extensions, and compliance reporting come built in
- Support, onboarding, and someone to call when it breaks
- Priced per company or per employee band rather than per seat, so the bill tracks how big you are, not how much hiring you do
- The features this template treats as core (scorecards, e-signature, offer management) are frequently mid or top-tier
- Two of the four vendors below publish no price at all above their entry tier
- Your candidates’ personal data lives on their servers under their retention rules
Priced per company against an employee-count selector, not per seat. The figures here are the 1-20 employee band the page opens on, and no price is published for the larger bands the same selector offers. Annual billing is quoted as a yearly total with a stated 20% saving. Watch the add-ons on Standard, which are what the sticker price leaves out: Texting+ $89/mo, Video interviews+ $109/mo, Assessments+ $59/mo, Performance & Engagement+ $39/mo, all bundled in from Premier up. The 15-day trial covers the Standard feature set but not Workable Agent.
workable.com · checked August 2026
Three named tiers and not one dollar figure anywhere on the page. Every button is “Get a demo”. Greenhouse’s own FAQ explains why, verbatim: “The cost of Greenhouse is influenced by the plan you choose (Core, Plus or Pro), your hiring volume and organizational complexity, and the features and capabilities required to support your workflows.” We quote no estimate of what it actually costs, because the vendor publishes none.
greenhouse.com · checked August 2026
Foundations is the only published price, and it is capped at 100 employees. Past that, verbatim: “Our pricing is based on company size, usage, and commitment.” Annual commitments carry a stated 10% discount. Ashby’s analytics product is priced separately, on usage, for teams running it over an ATS they already have.
ashbyhq.com · checked August 2026
The only genuinely free tier of the four, and its limit is the whole story: “1 Active Pool or Position”, with unlimited users and candidates behind it. Useful if you are hiring for exactly one job. The workflow this template ships is not on the entry paid tier either: scorecards, interview guides, and electronic signatures start at Growth ($273/mo annual), and offer management starts at Business ($439/mo annual), so a team wanting structured interviews and signed offers is comparing against those, not against $157. Annual billing is described as two months free.
breezy.hr · checked August 2026
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.
Why build with v0
v0 starts with the screens: forms, tables, dashboards, whatever the interface needs, generated in React and Next.js from a plain description. That’s the part most people notice first, because it’s fast and it looks finished immediately.
The backend isn’t automatic in the same way. v0 can write it too, meaning Next.js routes and server logic that read and write real data, but you ask for it, usually once the UI already exists and there’s something real to connect it to:
Sketch
Describe the screen or component you want.
Preview
See it rendered live, and select any part of it to adjust directly.
Connect
Add a database and the routes that read and write to it, once the UI needs somewhere real to save.
Iterate
Prompt again for the next screen or the next piece of logic.
The order matters here more than with a full-app builder: v0 gets you a finished-looking interface fast, and the data underneath doesn’t show up until you ask for it and give it somewhere to live.
One clickconnects a database
Supabase, Neon, and Upstash are integrations you add from the project menu once a screen needs to hold onto something real, and v0 provisions the credentials and writes the routes that use them.
Live preview is the feedback loop
Every prompt updates the working interface right there in the chat, so you see the actual screen changing instead of imagining it from a description.
Design mode edits without a prompt
Select an element in the live preview, adjust its style directly or type a plain-language instruction, and v0 applies the change back to the real source code as a new version.
Pay a developer, or do it with AI
Two ways to get the same app built: pay a developer for their hours, or spend your own describing it to an AI coding tool. Here is what each one costs to build, and what it costs to keep running once it is live.
Hire a developer
Custom build, from scratch- Developer
- ~$14k-$54k
- Supabase (backend)
- Free tier · $25/mo (Pro plan)*
- Hosting
- $0 free tier
- Build time
- ~270 hrs of their work
~$14k-$54k to build, then ~$25/mo after launch
That range is our ~270-hour estimate priced at market developer rates. The rate survey below puts North American contractors at $45-$75/hr and senior US developers at $100-$150+/hr, with agencies adding 20-40% on top, so roughly $50/hr at the low end, up to about $200/hr for an agency putting a senior on it. All of that is spent before your first candidate applies. After launch, your only standing costs are the database and the host.
Build it with v0
From scratch, with v0- v0
- $0 ($5/mo of credits) to $30+/month (Plus)
- Backend (Supabase)
- Free tier · $25/month (Pro plan)*
- Hosting (Vercel)
- Free on Vercel’s Hobby plan
- Your time
- ~128 hrs
Free to try the idea, ~$30+/month on Plus while you build a real one, then whichever plan you keep using
v0 bills in dollars of credit rather than a flat fee, so cost tracks usage: importing the pre-built template can fit inside Free’s $5 a month, while a from-scratch build runs into Free’s 7-messages-a-day cap quickly and usually needs Plus, at $30 per user per month with no annual discount shown. Because v0 generates the interface and the backend as separate steps rather than one pass, expect more prompts to reach the same result than a tool that writes both together.
* 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, v0.app, v0.app and vercel.com, checked August 2026.
Decide before you build
Settle these six and the build goes smoothly. Each is a decision about how your team hires, not code to write.
Your stages, named your way
Applied, screening, interview, offer, hired is the default nobody argues with and few teams actually use. Write down the stages your team really moves people through, including the ones you would rather not admit to, before anything is built around them.
Whether stages differ per role
An engineering hire with a take-home task and a sales hire with a role-play do not fit one stage list. Decide now whether every job shares one pipeline or each job defines its own, because retrofitting per-job stages later touches every screen that reads them.
Who can see which job
The decision that shapes the whole permission model. Options run from everyone sees everything, through per-department, to an explicit list of people per job. Confidential searches are the case that decides it: if you will ever run one, you need the per-job list.
What an offer has to pass through
Nobody, a manager, or finance and a manager in sequence. The approval chain is a workflow with states and notifications, so it is much cheaper to specify now than to add once offers are already going out.
How long you keep candidate data
Rejected candidates’ data does not get to sit in your database forever, and the rules differ by where you and they are. Pick a retention period and decide whether deletion is automatic or someone presses a button, then build to it.
Which outside services you actually need
A mail sender is not optional, since the system sends candidates real email. E-signature and AI resume parsing are. Decide which of the three you are wiring up before you build, because each one is an account, a key, and a fallback for when it is down.
Comparing your build options
The starting point decides how much of the work lands on parts nobody sees. Below is the same hiring system three ways: by hand, on a UI kit whose screens know nothing about candidates, or in v0, which generates those screens fast and then connects them to a real database when you ask.
The pipeline is the small part. Most of this is the work underneath it: a schema that survives a candidate applying to three roles at once, permissions per job rather than per person, resume files, an e-signature service, and a mail sender that does not land in spam.
You get a dashboard shell, a board component, and some table screens. None of them know what a candidate is. The schema, the stage rules, the scorecards, the offers, and every integration are still yours to write.
The screens arrive quickly and look finished immediately. The database and the routes behind them are a second, deliberate ask, so expect the same total split across more prompts than a tool that writes both in one pass.
Estimate your exact build timeframe
Tick the parts your hiring process actually uses. Plenty of teams never send an offer through the system, or never need a careers page. The estimate below follows what you keep.
Your estimate
128 hrs
start to finish
Based on the 7 of 7 features you’ve selected, plus ~31h of groundwork. Toggle any on the left to watch the number move, and open the groundwork row to untick what you have already, such as a database that is already running or going live if you are only building a mock-up for now.
A rough estimate, not a quote. Real time depends on how much you customize and how clean your data is.
Let’s set up the tools you need
v0 runs entirely in the browser too, so there’s no download and no terminal. Before step 01: sign up, pick a plan, and know that a database is one click away once a screen actually needs to save something. GitHub is the last piece, and it’s what turns the chat into a project you can hand to someone else.
v0 account
Sign in with a GitHub, Google, or email account and you land in a chat where you describe the interface you want. There’s nothing to install.
Sign up for v0v0 subscription
Free includes $5 of credits a month, capped at 7 messages a day, which is fine for trying a few screens and thin for a real build. Plus is $30 per user per month, billed monthly only (v0’s pricing page shows no annual option), and it’s the realistic floor once you’re iterating past a handful of screens.
Compare v0 plansDatabase (Supabase, Neon or Upstash)
Where your project keeps its data, added when a screen needs one. v0 generates the interface first. A database is a one-click integration you add from the project menu once a screen needs somewhere real to save to, with Supabase, Neon and Upstash as the options, and connecting one lets v0 write the routes that use it.
Connect a database in v0GitHub connection
Not needed to build anything, since v0 keeps its own history of every change. Connect a repository from the chat’s Git panel and v0 also commits every code-changing message to its own branch, ready to merge as a pull request. That is the step that turns the chat into a project other tools, and other people, can use.
Connect v0 to GitHubThe database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.
Build your hiring core, one chat at a time
v0 generates the interface first and the backend when you ask for it, so the order below runs slightly differently from the other guides: one screen, then the database that screen needs, then the rest. Keep one feature to one chat so its history stays a line you can follow.
- 01
Generate the pipeline board before anything else exists
Start with the screen your team lives in. It is the fastest way to find out whether your stage model is right, and it costs nothing to throw away.
PromptSketch the pipeline boardBuild a pipeline board screen for an applicant tracking system: columns for each hiring stage, cards for each application showing the candidate's name, the role, and how long they have sat in the current stage, with drag-and-drop between columns and multi-select for acting on several at once. Use placeholder data for now. I will connect a database next.
Placeholder data is fine here, and only here. Everything after this step gets something real behind it.
- 02
Add the database, then the tables the board needs
This is the deliberate second step v0 is built around. Connect a database from the project menu, then describe the model, and be explicit that a candidate and an application are separate records.
PromptConnect a database and design the modelConnect a Supabase database to this project, then create the tables this board needs and the API routes that read and write them. Jobs carry a title, department, location, employment type, description, and a status across draft, open, on hold, and closed. Candidates are the people, one row each, with name, contact details, and a resume file. A candidate exists independently of any single role. Applications join a candidate to a job, one per role applied to, each with its own stage, source, and outcome. Add job_stages so each job defines its own ordered stages. Then replace the board's placeholder data with real reads through those routes.
Ask for the routes in the same breath as the tables. A schema with nothing reading it leaves the screen exactly as fake as it was.
- 03
Start a new chat for auth and the per-job access list
Permissions are a feature of their own, so give them their own chat, so restoring a version later undoes the permission work without taking the board with it.
PromptAdd auth, roles, and job accessIn this chat, add authentication and the permission model. Email-and-password sign-up, login, logout, a session, and a profile row per team member. Then two layers: a role on each user (basic, job admin, or site admin) held in its own table rather than on the user record, since anything on the user record can be edited by that user. Then an access list per job naming who can open it, so a confidential search stays invisible to everyone not on it. Add a helper the access rules can call to answer whether a given user can reach a given job without recursing, and make every API route check it server-side rather than trusting anything the browser sends.
v0 routes run on the server, so the check belongs there. A permission enforced only in the component is a permission anyone can skip.
- 04
Put the same rules in the database, and on the resume files
The route check is the first line. Row-level security is the second, and it is the one that still holds if a route forgets to filter.
PromptAdd row-level security and storage rulesTurn on row-level security on jobs, candidates, applications, and job_stages, written against the job access helper, so the database enforces the same thing the routes do: a site admin reaches everything, a job admin reaches the jobs they are named on along with the candidates and applications attached to them, and a basic user gets that set read-only. Every insert and update needs an explicit check on which job the new row belongs to. Apply the matching rule to stored resumes: the bucket must not be public, and a file must not be fetchable by anyone who could not read its application. Then show me how to confirm a job admin querying a job they are not on comes back empty.
Two layers on purpose: the route can be bypassed by a bug, the database policy cannot.
- 05
Build the careers page, then tidy it with Design mode
The public application form is the one screen strangers use, so it gets its own chat and a proper pass on a phone-sized preview.
PromptBuild the careers pageIn a new chat, build the public side: a careers page listing open jobs, and a job detail page with an application form that takes contact details and a resume upload and creates the candidate and application through a server route, without requiring an account. Then add the internal candidate profile screen: their details, every application they have, and a timeline. Make sure the careers page works at phone width.
For visual fixes on this one, select the element in the preview and use Design mode rather than describing where it sits. It is faster and it changes the real code.
- 06Destination
Add interviews, scorecards, and offers, then open a pull request
Finish the process, click through it as an outsider, and merge, which, if that branch is the linked Vercel project’s production branch, also deploys it.
PromptAdd interviews, offers, and shipAdd the remaining pieces with their routes and tables. Interviews: a panel and a time booked against an application, emailing a calendar invite when set. Scorecards: the same questions for every interviewer at that stage, and a combined view showing who said what rather than an average. Offers: an approval that clears before sending, a generated PDF, and an e-signature request. Then help me walk the whole flow (post a job, apply through the careers page, move the application, book an interview, submit two scorecards, send the offer), and once it holds up, publish and open a pull request for it.
Protecting candidate data, and who sees which pipeline
A hiring system holds personal data about people who do not work for you and never agreed to anything beyond applying. Here is how that stays protected, in simple terms, and the rule that keeps it that way.
Proven logins for your team
Your colleagues sign in through the same battle-tested system every other app uses. You do not write login security yourself. Email and password works out of the box, and social sign-in is a small addition. Candidates applying through the careers page need no account at all.
Three roles, then a list per job
The template ships three roles (a basic team member, a job admin who runs the roles they own, and a site admin over everything) and then an access list per job on top. That second layer is what makes a confidential search possible: membership of the job, not seniority, decides who can open it.
Candidate data is the sensitive kind
Resumes, contact details, interview notes, and whatever someone volunteered in an application form. This is personal data about people outside your company, which raises the stakes on every access rule and makes your retention decision a real one rather than a formality.
Row-level security across every table
The template ships 133 row-level security policies because the interesting question is never “is this person logged in” but “is this person on this job”. The database answers that itself on every read and write, so a screen that forgets to filter still cannot leak another team’s pipeline.
Resume files need the same rules as the rows
An uploaded resume is a file in storage, not a database row, and it is easy to lock the candidate record down carefully while leaving the file itself reachable by anyone holding the link. Storage gets its own access rules, written at the same time as the table’s.
Four keys, and none of them ship to the browser
Only a “publishable” key reaches the app, and it is designed to be seen. The four that matter (the database’s service key, the e-signature account, the mail sender, and whichever AI model you use) stay on the server. A hiring system accumulates more of these than most apps, which is a good reason to route them all through one place rather than four.
Your database is the only copy until you pay for one
The free tier keeps no backups at all, so during the build a bad migration is unrecoverable. Supabase Pro (from $25/mo) adds a daily backup with 7 days of history. Get on it before the first real applicant, because losing candidate records is not a setback you can quietly rebuild from memory.
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.
Paste this into the chat before launch so v0 checks nobody can see data they shouldn’t.
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.
What speeds the build, and what slows it
Speeds the build
- One screen per message, checked in the live preview before you ask for the next one
- Adding a database as soon as a screen needs to remember something, so v0 wires it up as it builds
- Clicking the thing you want changed in Design mode, rather than describing where it sits
- One feature per chat, so its history reads as a straight line you can walk back
- Sending a finished chat over to GitHub before starting the next feature, rather than stacking several together
Slows the build
- Asking for the whole app in one message instead of one screen at a time
- Building screens for data the database does not hold yet
- Describing which button to change when you could just click it
- Letting one chat run for weeks, so going back to an older version undoes everything built after it
- Approving several messages in a row without looking at the preview after each one
Connecting GitHub (Optional)
Every change in v0 is saved automatically without any technical setup. You only need to link GitHub if you want a private copy under your own control or plan to hand the codebase over to external developers.
Every message is a version
Each time a message changes your code, v0 saves it as a new version. Restoring an older one adds it back as the newest version instead of branching, so the history stays one straight line.
Versions, v0 docsUndo from the chat itself
Scroll back through the conversation and click the revert arrow on any earlier reply, or open the version number in the top right to jump straight to a specific one.
Connecting GitHub creates a real repository
From the chat’s Git panel, connect an existing repository or create one. v0 never writes straight to your main branch: every code-changing message is committed to its own working branch first.
GitHub integration, v0 docsA pull request is how it gets merged
When you’re ready, publish and open a pull request from that working branch into your base branch, review it like any other, and merge it. Starting a new chat picks up a fresh branch for the next round of changes.
This can also be v0’s deploy path
If the branch your pull requests merge into is also the linked Vercel project’s production branch, merging one triggers a production deployment. If it isn’t, the merge just follows whatever branch behavior that Vercel project is already configured with.
GitHub integration, v0 docsWhere to host your application
Hosting gives your app a home on the internet so anyone can open it via a web link. Choose a service below to make your site live. (Your database, logins, and business records are stored separately in Supabase, covered below).
| Host | Best for | Notes | Free tier |
|---|---|---|---|
| Vercel | One-click deploys | Connect the project and it publishes itself. A standard Vite setup needs no configuration. One catch worth reading before you pick it: the free Hobby tier is for personal, non-commercial projects, and a hiring system for a company is neither, so budget for Pro at $20/user/mo. | Pro from $20/user/mo (Hobby is non-commercial) |
| Netlify | Drag-and-drop or Git | Either connect the repository or drag the built folder onto the page. The quickest way to get a careers page in front of someone who wants to see it today. | Free tier |
| Cloudflare Pages | Cheapest at scale | Connect it once and every applicant loads the careers page from whichever of Cloudflare’s locations is nearest them. | Generous free tier |
| GitHub Pages | Free Git-based hosting | Publishes straight from your GitHub project, with one small setting so page links resolve. The catch matters more here than on most projects: publishing from a private repository needs a paid GitHub plan, and a hiring system’s repo should stay private, so treat this as free only if you are comfortable making the code public. | Free from a public repo only |
| Firebase Hosting | Companies already on Google | Configure it once, then every release is a single publish command. Mostly worth it if your company already lives in Google’s tooling and this is one fewer vendor to explain. | Free Spark tier |
| AWS Amplify Hosting | Teams already on AWS | Connect the project in the AWS console and set one routing rule so deep links work. Worth it mainly if procurement has already blessed AWS. | Free tier (build + hosting) |
| Surge | Publish from the terminal | One command publishes the built folder, with no repository in the loop at all. Handy for showing a work-in-progress to a colleague. | Free - unlimited publishing |
| DigitalOcean App Platform | DigitalOcean users | Point it at the project and it builds and serves the site for you, alongside whatever else you already run there. | Free - 3 static sites, 1 GB/mo transfer |
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.
Keep your data in Supabase
Postgres for the records, auth for your team, storage for resumes and offer documents, and edge functions for anything that needs a key. Whichever host serves the frontend above, all four run here.
| Service | Best for | Notes | Free tier |
|---|---|---|---|
| Supabase | Data, auth, files, functions | Postgres database, authentication, storage for resumes and offer documents, and edge functions for the parts that need a key. Create a free project and your AI coding tool connects the app to it. | Free tier, then usage-based |
Where AI genuinely helps a hiring team
With the core working, each of these is one more prompt, and they go in as written. All four call the same server-side function, so the key sits on the server where no browser can read it.
Resume parsing into a real profile
Reads an uploaded resume and fills in the candidate’s roles, dates, skills, and contact details, so nobody retypes a CV into a form. The highest-value one on this list, because it runs on every single application.
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.
A screening summary against the role
Produces a short read on how an application lines up with the job description, with the specific evidence it used. It is there to save the recruiter a first pass, not to make the decision.
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.
Interview questions from the role and the resume
Drafts questions for a specific panel based on the job and what the candidate has actually done, so an interviewer walking in cold still asks something worth asking.
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.
Pulling scorecards into one view
Rolls a panel’s separate scorecards into a summary of where interviewers agreed and where they did not, so the disagreement is the thing that gets discussed.
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.
v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.
Get a head start with our template
Everything above assumes you are starting from an empty folder. You do not have to. The same hiring system is available already built, which turns most of that estimate into an afternoon of renaming stages to match your process.
Hiring & ATS
The exact ATS this guide builds, packaged so you can open it, point it at your own backend, and make it yours from there. An applicant tracking system for internal HR teams, agencies, and project-based hiring. Your team runs the whole process from one place - creating roles, tracking candidates, and moving them from application to offer - with AI resume parsing, shared interview scorecards, offers as signed PDFs, and real-time analytics on where every role stands.
The key benefits of starting with a template
The parts nobody enjoys building are already done and running: the schema, per-job access rules, resume storage, the offer chain, and three integrations. That leaves your time for the stages and scorecards that make it yours.
Building the core from scratch
~128 hrs
Opening the template, already built
~1 hr
~127 hrs of building you skip
Two different measurements, deliberately: ~128 hrs is what building the core costs you, and ~1 hr is how long the finished one takes to open and point at your own database. Adapting it to your stages, your scorecard questions, and your approval chain takes the same time whichever column you start from, so neither side counts it.
A working hiring system from day one
Open a functional app, not an empty folder. Jobs, candidates, the pipeline board, interviews, scorecards, offers, and the dashboard over them are ready to use.
Pre-configured access rules
Team accounts, three roles, a per-job access list, and 133 row-level security policies work out of the box, so a hiring manager reaches their own roles and nobody reaches a confidential search by accident.
The integrations already wired
Resume parsing, generated offer PDFs, e-signature, calendar invites, and transactional email are connected and working. Each one is an account and a key you supply, not a feature you build.
Clean structure your AI can safely customize
Typed throughout, organised by feature, and documented, which matters more than it sounds, because every later change you describe lands better when the tool has a clear pattern to follow.
From founders who build on our templates
We needed to get a live product in front of users fast. Instead of building from a blank repo, I picked up this template, customized it with our AI tool, and shipped straight away, bypassing the usual setup process.
Jeevan ThomasFounder & CEO, Hado.aiCommon questions
No, and you will not write the access rules by hand either. Describe what you need in plain language and your AI coding tool produces the schema, the row-level policies, the storage rules for resume files, and the server-side functions behind them. The one thing you do yourself is create a free Supabase project to point it at, so the data ends up somewhere you own.
Yes, and the data model is built for it. The candidate is one record. Each application to a specific job is its own record with its own stage, scorecards, and outcome. Someone can be rejected for one role and mid-interview for another without the two interfering.
Yes, and this is the part worth getting right early. Alongside the three roles, each job carries its own access list, so a confidential search is visible only to the people explicitly on it, enforced by the database rather than by hiding a link in the interface.
Yes. Resume parsing is the one most teams add first, followed by screening summaries, interview questions, and scorecard summaries. Add a small server-side ai function, pick the model tier that fits the job, and keep the key on the server, never in the app.
No, and the guide is written so it cannot. Every AI feature here summarises or extracts for a person who then decides. Nothing rejects an application on its own. Automated hiring decisions are regulated differently depending on where you and your candidates are, so check what applies to you before you go further than this guide does.
Only the services you connect with your own accounts: Supabase for the backend, a mail sender, and optionally an e-signature provider and an AI model. Supabase and hosting both start free. Before real candidates can apply, Supabase Pro starts at $25/mo, since free projects pause after 1 week of inactivity. You pay those providers directly.
Only the people your access rules allow, and it lives in the Supabase project you created. That makes you the sole controller of that data for GDPR purposes, which also means the retention decision is yours: decide how long rejected candidates’ records stay and build that in, rather than leaving them indefinitely by default.
There is nothing proprietary to be locked into. It is an ordinary PostgreSQL database, so an ordinary Postgres dump gives you every candidate, application, and scorecard, and any Postgres host will take it. Worth knowing for a second reason here: a request to delete a candidate’s data is much easier to honour when you can see exactly where all of it sits.
Yes. Whichever host you pick lets you connect a custom domain with free HTTPS in a few clicks, worth doing before the careers page goes out, since that URL ends up in every job ad.
No. You describe the screen you want in the chat and v0 generates the React and Next.js code behind it. Sign up, pick a plan, and connect a database once your screens need real data. The setup section above walks through each one.
Both, but not automatically at the same time. v0 generates the interface first. The backend (a database and the API routes that use it) is something you ask for once a screen actually needs to save or load real data.
Free plan credits reset monthly, and the 7-messages-a-day cap resets every day. If you hit either limit mid-build, what you’ve already built stays put. You wait for the reset or move up to Plus to keep going right away.
References
Sources checked August 2026- 01The Real Costs of Recruitment (average cost per hire), SHRM. shrm.org (published 2022)
- 02Pricing, Workable. workable.com
- 03Pricing, Greenhouse. greenhouse.com
- 04Pricing, Ashby. ashbyhq.com
- 05Pricing, Breezy HR. breezy.hr
- 06Pricing (Pro plan, free-tier limits, backups), Supabase. supabase.com
- 07Web developer hourly rates 2026 (freelance and agency benchmarks). developex.com
- 08Row Level Security, Supabase docs. supabase.com
- 09Storage access control, Supabase docs. supabase.com
- 10v0 homepage. v0.app
- 11Pricing (Plus, Business), v0. v0.app
- 12Pricing details (Free tier, credit rollover), v0 docs. v0.app
- 13Databases (connecting Supabase and others), v0 docs. v0.app
- 14Full-stack apps, v0 docs. v0.app
- 15GitHub integration, v0 docs. v0.app
- 16Deployments, v0 docs. v0.app
- 17Design mode, v0 docs. v0.app
- 18Versions, v0 docs. v0.app
- 19Pricing (Hobby plan), Vercel. vercel.com
This guide is general information, and not legal or HR advice. Hiring, candidate data, and automated decision-making are regulated differently depending on where you and your candidates are, so check what applies to you. Third-party prices, plan limits, and market rates are quoted from the sources above and were last checked on the date shown. Vendors change them without notice, so confirm before you budget. Build hours and the cost estimates derived from them are our own estimates, not quotes. v0 is a product of Vercel. Verify current capabilities and pricing before relying on them.