How to build an applicant tracking system with Bolt
Build a hiring system in one browser tab, starting from a GitHub repository. A careers page candidates apply through, a pipeline your team works, scorecards per interview, and signed offers, described in plain language, with the running app rebuilding in front of you after every message.
Bolt
$ Build an applicant tracking system in this project: a careers page people apply through, a pipeline board my team moves applications along, scorecards for each interview, and offers sent as signed PDFs, with access scoped to the jobs each person is actually on.
- Repository imported
- Schema and access rules built
- 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 Bolt
Screens are the easy part. What actually stalls a solo build is everything underneath them: somewhere real to hold the data people type in, permission checks on who can see it, and a UI that keeps working once more than one person is using it.
Bolt runs the whole thing in one browser tab, right down to the preview:
Prompt
Describe the screen or rule you want, in plain language.
Preview
Watch the running app rebuild itself in the same tab.
Try it
Click through the real app, because the preview is the actual build rather than a mockup.
Refine
Ask for the next change, or fix what’s off.
None of that needs an install or a terminal window, and the whole build happens in the tab GitHub just opened, one request at a time.
One tabruns the whole build
Bolt runs your project inside the browser itself, via StackBlitz’s WebContainers, so the preview you’re looking at is the app actually running, rather than a screenshot or a separate deploy you have to wait on.
Auto-committed to GitHub as you go
Once GitHub is connected, Bolt commits each working change on its own and pulls in anything you changed elsewhere, so the two stay in sync without you typing a git command.
Built-in database or your own Supabase
Ask for a database and Bolt wires up its own managed one with no extra account, or connects a Supabase project you already run yourself.
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 Bolt
From scratch, with Bolt- Bolt
- Free (1M tokens/mo) to $25+/month (Pro, from 10M tokens)
- Backend (Supabase)
- Free tier · $25/month (Pro plan)*
- Hosting
- Free on Bolt’s own hosting, or Netlify
- Your time
- ~128 hrs
Free for a first look. A real build costs from ~$25/month on Pro once it outgrows the entry token rung, and climbs from there with usage
Bolt bills by tokens, and the sticker price understates what a real build costs: it reloads your whole project as context on every message, so the entry Pro rung (10 million tokens for $25/month) burns down faster than the number implies. Budget for a top-up or a higher rung on a multi-session build, not the $25 floor. Lean on Bolt’s own token-saving tools (clearing context between features, pointing a prompt at specific files) to slow that burn.
* 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 bolt.new, 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
Your starting point decides how much of the build never reaches a screen. Here is one hiring system three ways: by hand, on a UI kit that stops at the front end, or in Bolt, where the whole project runs in the browser tab you are describing it into.
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.
Describe a piece and the running app rebuilds in the same tab. The preview is the real project, not a picture of it. Every working change commits itself back to your repository as you go.
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
Bolt runs in the browser, but it can’t open a .zip file, so the only way in is a GitHub repository. Do that first, then create a Bolt account and a plan. Everything after that is a plain description of what you want.
GitHub account
Bolt has no upload button for a folder or a .zip, and the only way to open a project is to import a repository, so a home for the code has to exist before Bolt does. Sign up and create a private repository, then push your project’s files to it.
Create a free GitHub accountBolt account
Sign up at bolt.new and connect the GitHub account from the step above. Once it’s linked, you pick a repository to import and land straight in a live preview, with nothing to install.
Sign up for BoltBolt subscription
Free gives you 300,000 tokens a day, capped at 1 million a month, which is enough to try Bolt rather than to finish a real app. Pro starts at $25/month for 10 million tokens (unused ones roll over one extra month), but Bolt reloads your whole project as context on every message, so a multi-session build tends to burn past that entry rung faster than the sticker number implies.
Compare Bolt plansSupabase (database)
Where your project keeps its data. Bolt can wire up its own managed database with no extra account, or connect a Supabase project you already run yourself, and both are Supabase underneath. Ask for one the first time a screen needs to save something real, so you have nothing to set up before you get there.
Connect Supabase to BoltThe GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.
Build your hiring core, one prompt at a time
Step 01 happens on GitHub rather than in Bolt, because a repository is the only way a project gets in. After that it is all one tab: prompt, watch the preview rebuild, click through it, prompt again. Clear the context between the unrelated features below, because it keeps each message cheaper.
- 01
Create the repository, then import it
Bolt has no upload button, so the project has to exist on GitHub before Bolt can open it. Create a private repository, import it, then set the ground rules in your first message.
PromptSet the project up after importingThis project is an applicant tracking system. Set it up as React 18 + Vite + TypeScript with Tailwind, and keep this vocabulary consistent everywhere from here on: jobs, candidates, applications, interviews, scorecards, offers. Note that we will add a database in the next step and every screen after that should read and write real data rather than placeholders.
Keep the repository private. Bolt commits to it automatically as you build, and a hiring system’s code has no business being public.
- 02
Talk the schema through in Plan Mode before it is written
The data model is the one thing that is expensive to change later, so use Plan Mode to agree it before Bolt writes a line, then connect the database and have it built.
PromptDesign the hiring data modelUse Plan Mode for this one. I need a database for a hiring system. 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, with name, contact details, and a resume file) and a candidate is not tied to any single role. Applications connect a candidate to a job, one per role applied to, each with its own stage, source, and outcome, so one person applying twice gets two separate histories. Add job_stages so each job sets its own ordered stages. Talk me through the plan first, then connect a database and build it.
Plan Mode costs a message and can save a rebuild. This is exactly the change worth spending it on.
- 03
Clear the context, then add sign-in and job access
Permissions have nothing to do with the schema conversation you just had, so clear the context first. Bolt reloads the whole project each message, and a clean slate makes this one cheaper.
PromptAdd auth, roles, and job accessAdd authentication and permissions. Email-and-password sign-up, login, logout, a persisted session, and a profile row per team member. Then two layers of access. A role on each user (basic, job admin, or site admin) stored in its own table rather than on the user account, because anything on the account is editable by the person it belongs to. And an access list per job saying who can open that specific job, so a confidential search stays invisible to anyone not named on it. Add a helper the access rules can call to answer whether a user can reach a job, without that rule calling back into itself.
Clearing the context between unrelated features is Bolt’s own advice, and it is the single easiest way to slow the token burn.
- 04
Lock the tables down, and the resume files with them
Point this prompt at the database work specifically rather than letting it range over the whole project. Then read what it produces. This is the step that protects candidate data.
PromptAdd row-level security and storage rulesWorking on the database layer only: turn on row-level security for jobs, candidates, applications, and job_stages, written through the job access helper. A site admin reaches every row. A job admin reaches the jobs they are named on plus the candidates and applications attached to them, with write access. A basic user gets the same set read-only. Give every insert and update an explicit check naming which job the new row may belong to. Then apply the same rule to stored resumes: the bucket must not be public, and a file must not be downloadable by anyone who could not read its application. Show me how to verify a job admin gets nothing back for a job they are not on.
Naming the layer keeps the prompt narrow, which Bolt charges you less for and which makes the result easier to check.
- 05
Build the careers page and the board, checking the preview between them
Two screens, two prompts, and a look at the live preview after each. The preview is the running app, so what you click is what a candidate would click.
PromptBuild the careers pageBuild the public half now: a careers page listing whatever is currently open, and a page per role carrying an application form that collects contact details plus a resume file, writing both a candidate and an application from it with nobody having to register first. Two things it must get right: it works at phone width, and it says plainly that the application arrived.
PromptBuild the pipeline boardThen the internal half: a board per job whose columns come from that job's own stage list, cards you can drag between them, and a way to select several at once to move or reject them together. Alongside it, a candidate page gathering that person's details, each application they have open, and a timeline of everything that has happened to them.
- 06Destination
Add interviews, scorecards, and offers, then publish
Close the loop, click the whole thing through as an outsider, then publish, to Bolt’s own hosting by default, or to Netlify if you would rather keep the domain there.
PromptAdd interviews, offers, and publishAdd what is left. Interviews: a panel and a time booked against an application, with a calendar invite emailed when it is set. Scorecards: the same questions for every interviewer at that stage, and a combined view showing who said what rather than one averaged number. Offers: an approval that has to clear before sending, a generated PDF, and an e-signature request. Then walk me through the full flow in the preview (post a job, apply through the careers page as an outsider, move the application, book an interview, submit two scorecards that disagree, send the offer), and once it holds up, publish 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 Bolt 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
- Using Plan Mode to talk a change through before Bolt writes any code
- Pointing a prompt at specific files or functions instead of the whole project
- Clearing Bolt’s context between unrelated features, so each prompt has less to process
- Checking the live preview after each change, since it’s the running app itself
- Reading the automatic GitHub commits later as a real history, not just a backup
Slows the build
- Asking for a whole app in one prompt instead of one screen or rule at a time
- Leaving context loaded from a finished feature while starting an unrelated one
- Editing the repository directly on GitHub and expecting Bolt to pick it up before its next 30-second check
- Approving several prompts in a row without checking the live preview after each one
GitHub: the way in, not just a backup
Bolt can’t open a .zip file, so the only way to start a project is to import a GitHub repository. Every other tool in this set treats GitHub as optional, but Bolt treats it as step one.
Why this comes before Bolt
There’s no upload button for a folder or a .zip. Opening a project in Bolt means pointing it at a repository that already exists on GitHub, so a home for the code has to exist first.
Create a free account, then a repository
Sign up, then create a new, private repository for your project and push your files to it. Keep it private, and never commit secret keys or passwords.
Create a free GitHub accountImport it into Bolt
On bolt.new, connect your GitHub account, choose the repository from the list, and click “Import repository”. The project opens straight into a live preview.
After that, it stays in sync on its own
Bolt commits each working change back to that repository automatically, and checks GitHub every 30 seconds for anything pushed from outside it. A commit is a snapshot with a short note, like “added the home page,” and Bolt writes those notes for you.
Version control and GitHub, Bolt docsIt’s also how you leave, if you ever want to
The repository Bolt is syncing is a real, ordinary codebase: clone it, hand it to someone else, or keep working on it directly on GitHub whenever you’re away from the browser tab.
Where 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.
Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.
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 what you want in the chat and Bolt writes the code and shows it running in the same tab. The one extra step Bolt asks for that other browser tools don’t is a GitHub account, since that’s how a project gets in. The setup section above covers it.
Bolt only opens projects from a GitHub repository, and it offers no upload button for a folder. Once it’s imported, Bolt keeps the two in sync automatically, so the extra step up front replaces a manual export later.
Free resets daily, and a paid plan’s monthly allotment resets on your billing cycle (unused Pro tokens also roll over one extra month). If you hit the cap mid-session, what you’ve built stays exactly as it is. You wait for the reset or buy more tokens 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
- 10Pricing (Free, Pro, Teams), Bolt. bolt.new
- 11Version control and GitHub, Bolt docs. support.bolt.new
- 12Connect Supabase, Bolt docs. support.bolt.new
- 13What is Bolt Cloud?, Bolt docs. support.bolt.new
- 14Netlify deployment (and Bolt hosting by default), Bolt docs. support.bolt.new
- 15Maximizing token efficiency, Bolt docs. support.bolt.new
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. Bolt is a product of StackBlitz. Verify current capabilities and pricing before relying on them.