Insights · 13 min read
An applicant tracking system puts the whole hiring pipeline in one place. Here is what it actually needs, what it costs to build, and the AI and compliance line to respect.
By GGP Editorial
Every hiring team hits the same wall. A dozen open roles, hundreds of resumes spread across a shared inbox and three spreadsheets, and a hiring manager asking where the last five interviews stand. The information is all there. It is just scattered, and nobody can see the whole pipeline at once.
An applicant tracking system, or ATS, is the software that fixes that. It holds the jobs, the candidates, the interviews, and the offers in one place, and it shows every person in the loop exactly where each candidate sits. This guide is for two kinds of readers: the company that is tired of running hiring on spreadsheets and wants to build an internal ATS, and the founder who wants to build and sell recruiting software. The two are different builds, and I will keep them separate.
I write this from the build side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects, and we have built enough internal business systems and SaaS products to know where recruiting software gets hard.
The term covers two different products, and confusing them is the first mistake.
An internal ATS is a tool a company uses to run its own hiring. The jobs are yours, the candidates are people applying to you, and the users are your recruiters and hiring managers. The buyer cares about review speed, a clean pipeline, and not losing a good candidate in an email thread.
A recruiting SaaS product is the platform you sell to other companies. You build it once and many customers run their hiring on it, which means multi-tenant architecture, per-tenant branding and configuration, and a higher bar for security and support. The buyer is a founder building a product business.
The two overlap after the candidate record and almost nothing else. An internal ATS can be single-tenant and opinionated about your workflow. A recruiting SaaS product has to accommodate every customer's different hiring process. Decide which one you are building before anyone writes a line of code. If you are still deciding whether to build at all, our piece on custom software vs SaaS covers the decision.
An ATS also sits next to, and is not, an HR system. The HR system holds employees once they are hired. The ATS holds candidates before they are. The handoff, where an accepted candidate becomes an employee record, is where the two integrate, and it is a seam people forget to budget for. We wrote the HR half of that in how to build HR software.
Before you budget a custom build, check the shelf. Mature ATS products cover the generic middle well.
Greenhouse, Lever, and Ashby serve growing companies with structured, opinionated hiring processes. Workable and JazzHR serve small teams that want something quick to set up. BambooHR bundles a basic ATS inside its HR suite. iCIMS and SmartRecruiters serve large enterprises with high-volume, multi-country hiring.
You should build when one of these is true. Your hiring workflow will not bend to the product, whether that is a specific approval chain, a particular scoring rubric, or a candidate experience you want to own end to end. Your candidate data has to live in a system you control, for privacy or compliance reasons. Or the recruiting software is the business you are selling, not a tool you use.
There is a middle path too. Buy a commodity ATS and build a thin custom layer where you differentiate, like a candidate-facing portal or a specific interview scheduling flow. Most companies that build from scratch do so because the pipeline itself is the product or the differentiator, not because off-the-shelf ATS is broken.
Recruiting tools get over-scoped fast. The clean split is between what you need to run a real pipeline and what you add once the model proves out.
| Must have in v1 | Can wait |
|---|---|
| Job postings and a career page | AI candidate ranking |
| Application forms and resume upload | Interview kits and scorecards |
| Candidate pipeline with stages | Automated scheduling links |
| Resume parsing into a structured profile | Offer approval workflows |
| Email notifications to candidates | Employee referrals |
| Hiring manager review and comments | Reporting dashboards |
| Basic reporting | Mobile app |
The pipeline itself is the product. If a recruiter can move a candidate from applied to screening to interview to offer, and a hiring manager can see that state and leave a note, you have the core. Everything else is optimization.
The visible half of an ATS is the candidate list. The hard half is the pipeline model, and it is where projects stall.
A candidate moves through stages: applied, screened, interview, offer, hired, rejected. That sounds simple until you model the details. A candidate can be in more than one process for more than one role. A stage has a due date and an owner. Rejection needs a reason, and some jurisdictions expect you to keep that reason recorded. Offers have approvals, and the moment a candidate accepts, the record hands off to onboarding or payroll, which is another system again.
The pipeline also has a time dimension. Hiring teams care about time-to-hire and where candidates get stuck, so the model records when a candidate entered and left each stage. That history is the difference between a glorified spreadsheet and a system that can tell you the funnel is leaking at the interview stage.
Model the pipeline before the data model, and model the data before the interface. The interface is easy to redo later. The pipeline model is not.
Resume parsing deserves its own section because it is the feature candidates judge you on.
A candidate uploads a PDF or a Word file, and the system turns it into a structured record: name, contact details, work history, skills, education. Parsing quality varies a lot by file format and language. The candidate sees the profile you auto-filled from their resume, and if the parser mangles their job titles or mixes up their dates, they assume the product is broken, even if the rest of it is fine.
Most ATS builds buy a parsing service or use an LLM-based parser rather than writing one from scratch. Parsing is one of those components where a mature third-party service is better than anything a small team builds in a sprint, and the cost is predictable. The same logic applies to anything else that is a commodity, like e-signature or video interviewing.
AI has real uses in recruiting, and a real boundary it should not cross.
The useful uses are text work. Parsing and structuring resumes, summarizing a candidate against a job description, drafting interview questions and outreach emails, and pulling a shortlist out of a large applicant pool. These fit the assistant role: the AI surfaces and summarizes, and a person makes the decision.
The risky use is any place an algorithm makes a consequential hiring decision on its own, like automated ranking that filters candidates out before a human looks. That is where compliance and fairness problems live, and the law has caught up with it. New York City's Local Law 144 requires employers to audit automated hiring tools for bias. The EU AI Act treats AI used in recruitment as high risk. The safe pattern is to keep a human in the loop and keep the AI on the drafting and summarizing side.
Privacy sits on top of that. Candidate data is personal data, so the system needs role-based access, an audit trail, retention limits, and a way to delete a candidate's data on request under rules like GDPR. Recruiters should not see data from roles they are not working on, and candidates should be able to ask what you hold on them. None of this is exciting, and all of it is where recruiting software either holds up or falls apart. Our explainer on how to add AI to existing business software covers the assistant-versus-decision-maker line in more detail.
Cost in an ATS build is driven by four things, in rough order of impact.
Team. A small senior team of a product manager, a designer, two backend engineers, and one or two frontend engineers is the typical shape. Where the team sits changes the bill a lot: a senior engineer through a China-based team runs roughly $5,000 to $8,000 a month, against around $12,000 to $16,000 for the same role on a US salary. We cover those numbers in what software development costs in China.
Integrations. Email, calendar, job board posting, and the HRIS handoff each add real time. Each third-party API is a line item, and some are slow to work with.
Parsing and AI. A good parsing service or LLM pipeline has a per-resume cost and integration work, and it scales with volume.
Tenancy. An internal single-tenant ATS is cheaper to build and run than a multi-tenant SaaS product with per-tenant configuration and isolation.
As a rough guide:
| Scope | What it includes | Typical range |
|---|---|---|
| MVP | Jobs, career page, application forms, parsed profiles, pipeline stages, email notifications, basic reporting, one or two integrations | $40,000–$90,000 |
| Mid-tier | Interview scheduling, scorecards, offer approvals, HRIS handoff, job board posting, several integrations | $90,000–$180,000 |
| Enterprise or SaaS product | Multi-tenant, per-tenant config, AI screening, compliance tooling, migration | $180,000+ |
Those are planning ranges, not quotes. The only number that matters is the one from a scoped proposal. Our walk-through on how to estimate a custom software project explains how to keep that number honest, and where the money goes in a custom build covers the drivers.
A scoped first version usually runs three to six months from kickoff to launch. An internal ATS can land in that window. A multi-tenant recruiting SaaS product with job board integrations and compliance tooling runs longer, often six to nine months. The spread comes from scope and third-party work, not typing speed. Plan for a discovery phase before anyone writes code, and a soft launch with a real department or a handful of pilot customers before you open the doors.
The way the system will be used shapes the data model early, so decide it up front.
Internal tool. One company, one set of rules, users are your own recruiters and hiring managers. Simpler permissions, no billing, no tenant isolation.
Recruiting SaaS product. Many companies, each with its own jobs, candidates, and configuration. This needs a multi-tenant design from the start, with tenant isolation, per-tenant settings, and a subscription and billing layer. It is expensive to bolt on later. We cover the trade-offs in multi-tenant SaaS architecture.
A point tool you sell, like a focused interview scheduler, has the smallest scope but still needs accounts, billing, and support from day one.
Scope the first version down to the shortest path a candidate and a recruiter can walk end to end: the candidate applies with a resume, the resume becomes a structured profile, the recruiter moves the candidate through stages, and the candidate gets a status email. If that loop works with the right permissions and an audit trail, everything else can follow.
Cut these from v1: AI ranking, scorecards, scheduling links, referrals, a mobile app, and most of the analytics. None of them remove the manual work a hiring team actually drowns in. The apply-to-stage loop does. Our guide on how to build a SaaS MVP walks through the same trimming logic.
The mistakes we see again and again are the same ones. Building the fancy AI screen before the basic pipeline works. Ignoring permissions until the end, so everyone sees every candidate. Under-scoping the recruiter side while polishing the candidate side. And treating the HRIS handoff as an afterthought, which turns a clean hire into a manual data entry job.
A focused first version from a small senior team typically lands between $40,000 and $120,000. An internal single-tenant ATS sits at the low end. A multi-tenant recruiting SaaS product with job board integrations and compliance tooling runs well past that.
Three to six months for a scoped first version is typical. A multi-tenant recruiting SaaS product often runs six to nine months.
Buy if an off-the-shelf tool covers your workflow. Build when your hiring process will not bend to the product, when you need to control candidate data, or when the recruiting software is the business you are selling.
Usually not. Use a parsing service or an LLM-based parser. Parsing is a component where a mature third-party service beats a small in-house build, and candidates judge you on its quality.
Yes, but keep a human in the loop. Use AI to parse, summarize, and shortlist. Do not let it make the final decision on its own, and check the bias audit requirements that apply to automated hiring tools in your market.
Internal tool, single tenant. Recruiting SaaS product, multi-tenant, and design it that way from day one.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, mobile apps, SaaS platforms, FinTech systems, ERP and CRM, and AI products on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node.
If you are planning an internal ATS, a recruiting SaaS product, or a focused hiring tool, send us the rough idea and we will help you scope the first version, estimate the budget, and figure out what to build first.
Tell us what you are building and where you are today. We typically reply within 24 hours.
