Build Your Own ATS in 2026: Scope, Steps and Costs

You can build your own ATS, and with an AI app builder a working prototype can take hours or days: a careers page, an application form and a simple admin panel where your team moves candidates through the hiring process.

The production work starts after that prototype. Candidates have to find the jobs, every applicant needs an answer, and your legal duties do not shrink with your budget.

This guide gives you a minimum architecture and build order, a hardening checklist, the routes from your own site to LinkedIn, Indeed and Google, the candidate-data duties your tool has to carry, what it costs to run, and when building is the right call.

Last verified: October 2026 against LinkedIn, Indeed, Google and UK and US regulator pages. This is general information, not legal advice.

Key takeaways

• The prototype is quick: AI app builders can produce a careers page, a form and a pipeline in hours or days.
• Build order matters: records and access rules come before screens. Email, board posting and data controls are where quick builds stop.
• Distribution is gated: a single company's site has no self-serve free feed onto LinkedIn, and Indeed allows three free direct posts a calendar month in the UK, US and ten other countries. Feeds need each board's approval and a developer.
• Data duties stay with you: you are the data controller either way. With a homegrown tool, your developer builds the controls and you hold the proof.
• The fee you avoid is small: a few hundred dollars a month for a company with dozens of staff. The net saving depends on developer time.

What a working ATS has to do

An applicant tracking system keeps a record of every applicant, every message and every decision, tied to the places candidates come from. The form is the part people see. The applicant record is where your team runs the hiring process.

For this guide we reviewed 17 employer-side ATS build tutorials on YouTube. The table maps what a working system has to do against what those quick builds usually include.

The first two columns describe what the ATS must do. The third shows how much a demo covers, and any missing parts become your responsibility once real applicants arrive.

A minimum ATS architecture and build order

If you build, build the records and the rules first and the screens second. Screens are cheap to change. A data model that cannot tell you everything you hold about one person is expensive to fix later.

These are the core records a small ATS needs:

• Jobs: title, location, description, status, open and close dates.
• Candidates: one record per person, matched on email.
• Applications: the link between a candidate and a job, with stage, source and the answers given.
• Stages and status history: every change, who made it and when.
• Users and roles: who can see and change which jobs and candidates.
• Notes and messages: interview notes, emails sent and replies received.
• Files: CVs and attachments in private storage, never behind a public link.
• Activity log: every view, edit, export and deletion.
• Consent and retention: when the data arrived, why you keep it and the date it is due for deletion.

Then build in this order:

1. Model the records. One candidate can have many applications, and every change writes a line to the activity log.
2. Publish job pages and the form. Give each job page JobPosting structured data from day one. The job-board section below explains why.
3. Store files safely. Keep CVs in private storage, connect each submission to one job and one candidate, and use email addresses to merge duplicate candidate records.
4. Add sign-in and access rules. Create roles, then test the rules with two separate accounts to confirm one cannot read the other's candidates.
5. Build the pipeline. Stages, notes, filters and status history, plus a required reason code whenever someone is rejected.
6. Wire up email. Send confirmations and rejections from your own domain and save replies on the candidate record.
7. Deploy and test the whole path. Submit a real test application and check that it lands, the emails go out and the record is complete.

Where AI app builders fit

AI app builders and coding assistants can shorten steps 2 and 5, and part of step 4. Lovable builds React apps with a Supabase-based backend. Bolt builds JavaScript apps on its own database by default. Paid plans for both start at $25 a month.

One non-developer described building an internal applicant tracker with an AI coding assistant in about three hours, in a Reddit build report. Sending emails to candidates was still on the to-do list.

Lovable is clear about who owns the rest. Lovable's security documentation says the app owner is responsible for meeting the security needs of the use case and that its built-in scans cannot guarantee complete security.

The same page names misconfigured row-level security as a common cause of data leaks. That has history: in 2025 a researcher reported insufficient row-level security in apps generated on Lovable, logged as CVE-2025-48757. Lovable disputes the report.

Hardening a homegrown ATS for production

A prototype proves the screens work. Production means the system keeps working when nobody is watching, and holds up when a candidate, a regulator or a tribunal asks what happened. Treat this as a minimum checklist, not a complete one.

• Access: roles and record-level rules tested with two throwaway accounts on every screen, and no secret keys in browser code.
• The form: limits on file size and type, malware scanning for uploads, spam and bot protection, an accessible layout, and a scheduled test application that alerts you when submissions stop arriving.
• Email: SPF, DKIM and DMARC set up on the sending domain, with bounces and replies saved to the candidate.
• Data controls: a retention timer with automatic deletion, one export of everything you hold about a person, deletion that reaches inbox copies, downloads and backups, and an audit history of who viewed and changed what.
• Running it: backups with a restore you have actually tested, uptime and error alerts, and a routine for dependency and platform updates.
• Ownership: a named person for access requests, broken uploads and incidents, plus written notes that let someone else take over.

Mistakes that show up in real builds

Three patterns from public build reports and practitioner threads:

• One poster reported that a DIY stack on Notion, Zapier and Make stopped being dependable after about two weeks, with failing automations, slow retrieval and duplicate records (r/smallbusiness).
• A step-by-step tutorial opened the Google Sheets holding applicant form submissions to anyone with the link, so the app could read them (video at 28:35).
• A CV deleted in the app lives on in inboxes, downloads and printouts, so the deletion request is only half done.

One honest limit on the evidence.

A large outsourcing firm with its own engineers built an ATS around 2014 and, by its own account, now hires about 8,000 people a year. Beyond that firm, we found no first-hand account of a small employer running a homegrown ATS for a year or more.

The upkeep stories come from other homegrown tools, such as one r/webdev poster's report of AI-built projects being rewritten about 18 months after launch. Read them as risk patterns, not a failure rate.

Getting jobs onto LinkedIn, Indeed and Google from your own site

A careers page is not distribution. Candidates reach jobs through job boards and search engines, and each board decides how jobs get in. Here is what a homegrown site can do on each one.

LinkedIn

Posting by hand gives you one free job at a time. It pauses after 14 days or once it reaches an applicant cap, typically 10 to 30 applications, and you have to promote it to unpause it. Repost the same job within 7 days and LinkedIn requires you to promote it.

LinkedIn ingests free Basic Jobs from partner feeds, job boards and some career sites. The XML feed program is limited to LinkedIn-approved developers serving verified paying users, and LinkedIn estimates the build at 2 to 8 weeks.

Its Job Posting API is not accepting new partners. So a single company's own site has no self-serve free feed onto LinkedIn. Promoted jobs are billed per click against a daily or total budget, and LinkedIn publishes no fixed price.

Indeed

A direct employer has three routes onto Indeed:

• By hand: up to three free jobs per calendar month, each shown for up to 30 days, in 12 countries including the UK. Accounts linked to the same parent company share the limit. Beyond that, jobs need sponsoring to stay visible.
• Your careers site: you can ask Indeed to collect jobs from it, with no guarantee they will be included.
• Your own feed: a direct employer can build an XML feed or a Job Sync API connection. Indeed's developer guide asks for a signed Developer Agreement and a developer who knows HTTP, XML and JSON, and estimates that setup, testing and review take about six weeks.

Indeed's single-source feed policy says homegrown systems are not affected. Indeed's pricing page says jobs from career sites and feeds may require sponsoring, so no route promises free visibility.

For jobs posted directly, applications sit in your Indeed account and conversations in Indeed Messaging. Exporting candidates in bulk needs a minimum spend over the previous 12 months: $10,000 in the US or £3,000 in the UK.

Google for Jobs

Google has no approval step, but the upkeep is yours. Each live job page needs valid JobPosting structured data with the required fields (title, description, date posted, hiring organization and location), and the job must be readable without a login.

When a job closes, mark it expired or take the page down without delay. Google says failing to act on expired jobs can lead to a manual action against the site. The Indexing API can speed up crawling of job pages, within a default quota of 200 publish requests a day.

Put together, the pattern is simple. Unless your developer builds and maintains approved integrations, jobs on LinkedIn and Indeed are created, updated and closed by hand, apart from what Indeed collects from your site. Google reads your job markup directly.

Candidate data: the duties your own tool has to carry

Data protection law treats you as the data controller whether you build an ATS or buy one. Buying does not make you compliant, and building does not add a new legal role.

What changes is the work. With a homegrown tool, your developer builds the controls and keeps them running, and you keep the records that show they worked. The table covers UK rules, with the main US points at the end.

Under the EU GDPR the one-month, erasure and 72-hour rules are the same, fines are set in euros, and the 2026 UK changes do not apply.

If you buy, you still configure these controls yourself. Our page on GDPR-compliant ATS controls shows how that works in 100Hires. The question here is who builds them.

What getting it wrong can cost

UK fines have two ceilings. Failures of core principles and individual rights, such as access and erasure, can reach £17.5 million or 4% of worldwide turnover, whichever is higher.

Breaching the security duty (Article 32) or the breach-notice rules (Articles 33 and 34) can reach £8.7 million or 2% of worldwide turnover, whichever is higher. A security failure that breaches the Article 5 security principle sits in the higher tier (Article 83).

Those are ceilings. The regulator scales fines to company size: its published starting points for a micro business (turnover up to £2 million) run up to about £70,000 for serious higher-tier cases, before adjustments, and it can act without a fine at all.

Fines are not the only route. Anyone who suffers damage or distress from a breach of the rules can claim compensation under Article 82 of the UK GDPR, and tribunal compensation for discrimination has no upper limit.

None of this changes with the tool you pick. What changes is who builds, maintains and documents the controls and the evidence. If that knowledge sits with one developer, you carry an extra continuity risk.

Building can avoid a subscription fee of a few hundred dollars a month, but that is not the same as a net saving. The duties stay with you either way, and the law caps their penalties in the millions or, for discrimination, not at all.

DBS checks, visa status and licences on the application form

Some field-service and driving employers ask about criminal records, right to work and licences up front. Each comes with its own rules:

• Criminal records: this data has its own legal regime and usually needs an appropriate policy document. The ICO's draft recruitment guidance says not to ask for a criminal records declaration on the application form as a rule, and suggests asking at the conditional-offer stage.
• DBS certificates: government guidance says certificate information should usually be destroyed within six months.
• Right to work: Home Office guidance says to keep copies of the check for the person you employ for the length of their employment plus two years.
• Nationality: it is not special category data under the UK GDPR, but it is part of race under the Equality Act, so screening on it carries discrimination risk.
• Driving licences: the DVLA's online check only works with a one-time code the driver gives you.

A form that asks every applicant these questions collects sensitive, decision-relevant data from everyone, long before the hiring stage needs it.

One company's homegrown ATS

Here is one case we looked at in October 2026. A UK gutter and roof maintenance company with about 80 staff hires heavily in its peak season, when 800 to 1,500 CVs arrive a week. That month, instead of buying an ATS, it launched a careers site and a mini-ATS built on Lovable.

What it has: its own careers site and an admin panel for its team. What it does not have: a feed to any job board.

About 40 jobs on Indeed were posted by hand, it has one paid promoted job on LinkedIn, and the form collects DBS, visa status and driving licence answers.

It is one observed case, and its results after launch are unknown.

The published limits do show one thing. If most of those 40 jobs are posted in the same month, three free direct Indeed posts cannot cover them, so the rest depend on sponsorship, Indeed picking jobs up from the careers site, or another route.

Volume is the other pressure point. For example, opening 1,000 CVs in a peak week at 30 seconds each takes more than eight hours before anyone replies to an applicant.

What it costs and what you get

A fair comparison weighs the ATS subscription you would avoid against the work your team takes on when it builds its own system. The net saving depends on developer time, builder fees, hosting, email delivery, monitoring and maintenance, and no price list shows those.

Prices below are for a company with 51 to 100 employees.

For a company with dozens of staff, building an ATS avoids a subscription fee of a few hundred dollars a month. Your team then takes on the checklist above and the data duties, plus a continuity risk if only one developer understands the system.

Our ATS pricing guide lists costs for every company size.

When building makes sense, and when buying does

Building is the right call in three situations:

• Very low volume with one owner: if you hire a few people a year, a form and a spreadsheet that one person maintains can be enough.
• Recruiting is your core business, or you have an engineering team and high applicant volume: the outsourcing firm mentioned above built its own system with an in-house engineering team.
• You want a custom front end: keep an ATS as the system of record and build only what candidates see. With 100Hires that means a custom domain on Advanced and up, an embed, or a careers page built on the public Career Site API included in paid plans.

Buying makes more sense when:

• you make several hires a month or have seasonal peaks
• you need LinkedIn and Indeed reach without building and maintaining integrations
• your form collects right-to-work, criminal record or licence data
• nobody on the team can own the tool for years

If you decide to buy, our guide on how to choose an ATS walks through requirements, demos and red flags.

Frequently asked questions

Can I build my own ATS with Lovable or Bolt?

Yes, a prototype with a careers page, a form and a pipeline can take hours or days, on plans from $25 a month. Production needs access rules, email, board posting and data controls. Or keep 100Hires as the back end and build the careers front end on its Career Site API.

What is the minimum data model for a homegrown ATS?

Jobs, candidates, applications linking the two, stages with status history, users and roles, notes and messages, private file storage, an activity log, and consent and retention dates. 100Hires keeps equivalent records, so it is a useful model to compare against.

How long does it take to build an applicant tracking system that is ready for production?

Prototypes we reviewed ranged from 20 minutes in a vendor demo to about three weeks of evenings. Feeds take longer: LinkedIn estimates 2 to 8 weeks for approved partners, Indeed about six weeks for a direct employer. A 14-day 100Hires trial needs no card.

Can a homegrown careers site post jobs to LinkedIn and Indeed?

Yes, by hand within free limits: one free LinkedIn job at a time and three free Indeed jobs a month in the UK and US. Beyond that, you sponsor jobs or build feeds each board must approve. 100Hires connects to Indeed through Job Sync, but both boards still decide placement.

How long should we keep job applications?

In the US, covered employers keep application records for at least one year. UK law sets no fixed period, and the ICO expects a written retention policy. In 100Hires you set a retention period from 1 to 60 months with automatic deletion. General information, not legal advice.

Try 100Hires free for 14 days on your next role, with no card required, and compare it with your build plan.