How to build an applicant tracking system with Lovable
Build a hiring system in a browser tab, prompt by prompt. Candidates apply through a careers page you designed, your team works them along a shared pipeline, interviewers score against the same questions, and offers go out signed, with Lovable designing the tables, the logins, and the access rules from the same chat that builds the screens.
Lovable
$ Build an applicant tracking system: a careers page candidates apply through, a pipeline board my team moves them along, scorecards each interviewer fills in, and offers sent as signed PDFs, and set the access rules so a hiring manager only sees the roles they are on.
- Tables designed from the chat
- Access rules per job
- 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 Lovable
A working app needs more than screens: something has to store what people enter, decide who may see it, and reject what does not make sense. That part is where a solo build stalls, not the parts a user sees.
Lovable turns that work into a conversation: describe a screen or a rule in plain language and watch it appear in the live preview, in the same tab:
Prompt
Say what you want to add or change, in plain language.
Watch
The live preview rebuilds in the browser as Lovable writes the code.
Try it
Click through the real app, with real buttons, forms and data rather than a mockup.
Refine
Select what’s off and describe the fix, or ask for what’s next.
None of that requires a computer science background or writing code, and the whole build happens in one browser tab, one request at a time.
Data & backendhandled automatically
Connect your database in a single step, right from the chat. Lovable builds the tables, sets up the logins, writes the server-side functions, and turns on live updates, each one an ordinary request in plain language, not a separate tool to learn.
Click to point instead of describing where
Select any element in the live preview with Lovable’s Select elements tool, and your next message applies to exactly that piece.
Full ownership and complete privacy
The app and the records in it are yours. Every change is saved automatically, and the repository Lovable syncs to GitHub is private on every plan, with no technical setup and not one Git command.
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 Lovable
From scratch, with Lovable- Lovable
- Free (30 credits/mo) to $25+/month (Pro, from 100 credits)
- Backend (Supabase)
- Free tier · $25/month (Pro plan)*
- Hosting
- $0 on a Lovable subdomain
- Your time
- ~128 hrs
Free to try the idea, ~$25-$50+/month on Pro while you build a real one, then whichever credit tier you keep using
Lovable bills by credits, so what you pay tracks what you build: importing the pre-built template can fit inside the Free plan’s 30 credits a month, while a full from-scratch build burns through Free fast and usually needs Pro. Pro’s entry rung is $25/month (or $250/year, roughly $21/month effective) for 100 credits, the bottom of a ladder where 200 credits runs $50/month (or $500/year, about $42/month), and a multi-session build often lands on that rung or higher rather than the entry price.
* 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 docs.lovable.dev, 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
How you start decides how much of this is plumbing versus the parts your team will actually use every day. Here is one hiring system built three ways: by hand, on a UI kit with nothing behind it, or in Lovable, where the tables and the screens come out of the same conversation.
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 screen or a rule and watch the running app change in the same tab. Connect Supabase once and the tables, the logins, and the access rules come from that same chat, with no install and no terminal at any point.
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
Nothing gets installed, because the whole workspace is a browser tab. Three things to sort out before step 01, and a fourth worth adding once the project matters to you. After that, you build by describing what you want.
Lovable account
Nothing to download. Sign up with an email, Google, or GitHub account and you land straight in the chat where you describe what to build.
Sign up for LovableLovable subscription
Lovable bills by build credits, so the plan you need follows what you build. Free gives you 5 credits a day, capped at 30 a month, which is enough to try it rather than to finish an app. Pro is $25/month for 100 credits ($250/year, about $21/month), and that is the bottom rung: a build spread over several sessions usually lands on 200 credits at $50/month, or higher.
Compare Lovable plansSupabase project
Where your app keeps its data. Connect your own Supabase project from the chat, or let Lovable create one for you. Either way it designs the tables, adds the logins, and wires the screens to them from there.
Connect Supabase to LovableGitHub connection
Not needed to build anything, since Lovable keeps its own history of every change. Link a GitHub account and it also keeps a private repository in sync, so a copy of the real code exists outside the browser tab. Worth doing before the project is one you would hate to lose.
Set up GitHub syncOnly the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.
Build your hiring core, prompt by prompt
Everything below happens in one browser tab. Send a message, watch the preview rebuild, click through what changed, then send the next. The order matters more than usual here: connect the database before you ask for screens, or you build forms with nowhere real to save to.
- 01
Connect Supabase before you ask for a single screen
The most common way a Lovable build goes sideways is building screens first and adding the database later. Connect it from the chat now, and every screen after this has somewhere real to write to.
PromptConnect the backend and set the ground rulesConnect this project to Supabase before we build anything. Once it is linked, note the conventions for the rest of this build: this is an applicant tracking system, so we will use jobs, candidates, applications, interviews, scorecards, and offers as the names throughout, and every screen should read and write real Supabase data rather than placeholder content.
Connect it first and Lovable designs tables as it goes. Connect it later and you rebuild the screens that were saving nowhere.
- 02
Describe the tables, starting with the split that matters
Ask for the data model in one message, and be explicit that a candidate and an application are different things. Lovable will happily merge them if you describe them as one.
PromptDesign the hiring data modelDesign the database for this hiring system. Jobs hold a title, department, location, employment type, description, and a status covering draft, open, on hold, and closed. Candidates are people (one row each, with name, contact details, and their resume stored as a file) and a candidate exists on their own, not inside a job. Applications link a candidate to a job, one row per role they apply to, each carrying its own stage, source, and outcome, so applying to two openings gives them two separate histories. Add job_stages as well, so each job can set its own ordered stage list instead of every role sharing one. Show me the tables and how they relate before you build any screens on them.
Say “a candidate exists on their own” out loud in the prompt. Describe them together and you get one table, and a rewrite the first time somebody reapplies.
- 03
Bookmark this version, then add logins and job access
Changes to the data model and the access rules are the ones worth being able to undo in a click. Bookmark first, then ask for both layers of permission in one message.
PromptAdd auth, roles, and job accessBookmark the current version first, then add authentication. Email-and-password sign-up, login, logout, and a profile row for each team member. Then two layers of permission. First a role on each user (basic, job admin, or site admin) stored in its own table rather than on the user account itself, because anything on the account can be edited by the person it belongs to. Then an access list per job, naming which users can open that job, so a confidential search is only visible to the people on it. Add a helper the access rules can call to answer “can this user reach this job” without the rule calling back into itself.
Bookmarking before a change to the data model is the difference between one click back and a long scroll through history.
- 04
Ask for the access rules, then check them with the audit prompt
This is the step that decides whether candidate data is protected. Ask for it explicitly, including the resume files, and then have Lovable read its own work back to you in simple terms.
PromptAdd row-level security and storage rulesTurn on row-level security for jobs, candidates, applications, and job_stages, using the job access helper. A site admin can reach everything. A job admin can read and change the jobs they are on, plus every candidate and application attached to those jobs. A basic user sees that same set but cannot change it. Every insert and update needs an explicit check that the new row belongs to a job the person can actually reach. Then apply the same rule to the stored resumes: the file bucket must not be public, and someone who cannot open the application must not be able to download its resume either. Then show me how to confirm a job admin gets nothing back for a job they are not on.
Resume files sit outside the tables, so they need their own rules. Securing the rows and leaving the bucket public is the version that looks done and is not.
- 05
Build the careers page, then the board, in that order
Two screens, two messages, previewed separately. Ask for the public one first: it is the one that has to work on a stranger’s phone.
PromptBuild the careers pageBuild the public side first: a careers page listing every open job, and a job detail page with an application form that takes contact details and a resume upload, creating the candidate and the application without asking anyone to make an account. It has to work on a phone, and it has to tell someone clearly that their application went through.
PromptBuild the pipeline boardNow the internal side: a pipeline board for a single job, using that job's own stages as the columns, with drag-and-drop to move an application between them and multi-select for moving or rejecting several at once. Then a candidate profile page pulling together their details, every application they have, and a timeline of what has happened. Use Select elements to point me at anything you want me to adjust rather than describing where it is.
- 06Destination
Add interviews, scorecards, and offers, then apply to your own job
Close the loop to a signed offer, then use the preview as an outsider would. The careers page is the part your own team never tests.
PromptAdd interviews, offers, and testAdd the rest of the process. Interviews: booking a panel and a time against an application, and emailing a calendar invite when it is set. Scorecards: the same questions for every interviewer at a given stage, with a combined view showing who said what rather than one averaged score. Offers: an approval that has to clear before anything sends, a generated PDF, and an e-signature request. Then walk me through the whole thing in the preview: post a job, apply through the careers page as an outsider, move the application along the board, book an interview, submit two scorecards that disagree, and send the offer.
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 Lovable 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 small request per message, such as a field, a screen or a rule, rather than the whole app at once
- Connecting your database before building screens that need real data, not after
- Using Select elements to point at the exact thing that should change, instead of describing its location in words
- Bookmarking a known-good version before a redesign or a change to the data model
- Reading each response before sending the next request, so small mistakes don’t stack up
Slows the build
- Asking for an entire app in one message instead of one screen at a time
- Building screens for data your database does not hold yet
- Describing which button or section to change instead of selecting it
- Skipping bookmarks, then scrolling far back through history to undo a bad change
- Approving several messages in a row without previewing what actually changed
Connecting GitHub (Optional)
Every change in Lovable 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.
What Git actually is
A recorder for a project: every change becomes a version you can go back to, and nothing is ever overwritten. GitHub is the service that keeps those versions online.
Lovable already saves every change
A new version is created each time Lovable changes your project. No save button, no Git command, and the full history is there to scroll back through.
Version history, Lovable docsReverting undoes the code, not your data
One click restores an earlier version of your code and redeploys it, but nothing already written to your database rolls back with it. A UI or logic change is safe to undo. A change that touched real records is not.
Bookmark before a big change
Before a redesign or a change to your data model, bookmark the version you are on: one click back instead of a long scroll through history.
Connecting it, if you want to
Open your project settings, pick GitHub, and authorise the account. Lovable creates a private repository and keeps it in sync both ways: changes in Lovable reach GitHub, and anything pushed to that branch comes back in. Free on every plan.
GitHub integration, Lovable docsIt’s also how you leave, if you ever want to
The synced repository is a standard Vite and React project: clone it, hand it to a developer, or deploy it yourself.
Deployment, hosting, and ownership, Lovable 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 |
|---|---|---|---|
| LovableBuilt in | Publishing from the chat | The project you have been previewing publishes itself, with nothing to configure and no account to open anywhere else. Free on any plan at a lovable.app address. Paid plans put it on your own domain: buy one through Lovable and the DNS is done for you, or point one you already own at it using the two records the setup screen shows. Certificate issued automatically either way. | Free on a lovable.app subdomain · own domain on paid plans |
One button, and the app you have been previewing is live.
Hosting it somewhere else
Only for a setup Lovable does not offer: a host you already pay for, or the exported code on your own account. None of it is needed to go live.
| 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.
You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.
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. Everything happens in a browser tab: you describe what you want in the chat, and Lovable writes and previews the code. The setup section above covers the handful of things you connect first: an account, a plan, and your own Supabase project.
A sketch on the Free plan is fine for testing an idea, with no real backend behind it. A project connected to your own Supabase account is the one you can actually launch, with real logins, real data, and your own domain.
Build credits reset every day (Free) or on your billing cycle (paid plans). If you run out mid-session, the app you’ve built stays exactly as it is. You either wait for the reset or move up a credit tier 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
- 10Sign up, Lovable. lovable.dev
- 11Subscription plans (Free, Pro, Business), Lovable docs. docs.lovable.dev
- 12Connect Supabase, Lovable docs. docs.lovable.dev
- 13GitHub integration, Lovable docs. docs.lovable.dev
- 14Deployment, hosting, and ownership, Lovable docs. docs.lovable.dev
- 15Version history and reverting, Lovable docs. docs.lovable.dev
- 16Preview toolbar (Select elements), Lovable docs. docs.lovable.dev
- 17AI features and model selection, Lovable docs. docs.lovable.dev
- 18Custom domains, Lovable docs. docs.lovable.dev
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. Lovable is a product of Lovable Labs. Verify current capabilities and pricing before relying on them.