How I Built a Custom ATS for a 300-Person Company in About Two Months

I built the first version of a custom applicant tracking system for a company with roughly 300 employees in about two months.

More than three years later, the company still uses it every day. The system now contains over 20,000 résumés and supports the recruiting team from application intake through vacancy work, evaluation, and reporting.

The most important part of this case is not that the system includes AI. It is that a relatively fast low-code build became durable operational infrastructure instead of a short-lived prototype.

This article explains the architecture, what the system actually does, why the first version could be delivered quickly, and where a custom ATS makes more sense than buying another enterprise platform.

The company remains anonymous, and I am deliberately omitting candidate data, internal screens, and sensitive implementation details. The scale and operational facts in this article come from the live system; I am not attaching an estimated dollar value to them.

The case in numbers

The simplest summary is:

company size: approximately 300 employees;
initial development: roughly one to two months;
production use: more than three years;
usage: part of the recruiting team’s daily work;
current database: more than 20,000 résumés, with the real lifetime volume higher than the conservative count used here;
resume intake: a custom Chrome extension integrated with HeadHunter;
main interface: AppSheet;
automation and integration backend: n8n;
operational database: MySQL;
AI function: résumé summarization inside the larger workflow.

Those numbers describe endurance, not a demo. The system continued to carry the process as the candidate database and operational history grew.

The problem was larger than storing résumés

The company recruits continuously. That creates a much broader operating problem than keeping candidate files in one place.

The HR team needs to:

collect applications and connect candidates to the right vacancies;
support different pipelines and stages for different vacancies;
coordinate several people working on the same vacancy;
control who can see or change different records;
preserve discussions, contacts, emails, and work history;
move candidates through defined statuses and retain the history;
communicate through email and messenger integrations;
record user actions and changes for auditability;
evaluate team activity and performance;
reduce the time spent reading and summarizing long résumés.

An enterprise ATS can cover many of these capabilities. The decision was not based on the idea that commercial ATS products are incapable. The issue was fit: the company needed the software to follow its recruiting process instead of reorganizing the process around a generic product model.

That is the same distinction I described in CRM vs a Custom System: once software is expected to run a business-specific process, feature count matters less than how accurately the system represents the actual work.

The architecture: extension, n8n, MySQL, and AppSheet

The system uses a hybrid low-code architecture.

1
2
3
4
5
6
7
8
9
HeadHunter -> Custom Chrome extension -> n8n
                                         |
                                         v
                                       MySQL
                                         |
                                         v
                                      AppSheet

Connected channels: email and messengers

Each layer has a narrow responsibility. The extension moves recruiting data out of the browser workflow. n8n coordinates intake and backend automation. MySQL stores the growing operational dataset. AppSheet gives the recruiting team an interface for running the process.

The custom Chrome extension

The intake process starts where recruiters already work: the HeadHunter website.

I developed a separate Google Chrome extension that integrates with the site and transfers résumé data into the ATS. This avoids asking recruiters to copy candidate information field by field or maintain a parallel spreadsheet before a candidate can enter the internal workflow.

The imported profile can include the information the team needs later:

employment history;
education;
social profiles;
tags;
contact details;
the résumé and its relationship to a vacancy.

HeadHunter maintains an official API for integrating vacancies, résumés, employer accounts, and application or invitation workflows into other products.¹ In this system, the browser extension and the n8n integration layer bridge the external recruiting platform with the internal ATS.

n8n as the integration and automation layer

n8n connects the Chrome extension and HeadHunter intake with the ATS backend and database workflows.

It is the backend coordination layer rather than the place where recruiters work directly. This keeps integration logic, automated actions, and external system calls outside the AppSheet interface.

MySQL as the operational data layer

AppSheet works on top of a MySQL database.

That detail matters because this is not a small spreadsheet prototype. The database holds a large and growing set of résumés, vacancies, status histories, discussions, user activity logs, targets, and operating records.

The relational data layer gives the system a stable structure for connecting a candidate to a vacancy, a vacancy to a hiring team, and each status or discussion event to the relevant process.

AppSheet as the operational interface

AppSheet gives the recruiting team one place to work with:

candidates and their résumés;
open and historical vacancies;
teams assigned to individual vacancies;
contacts and communication records;
discussions and internal notes;
current candidate status and full status history;
role-specific views and permissions;
team KPIs and performance evaluation.

This is exactly the kind of internal, data-driven application where I often prefer AppSheet: the interface needs to make structured work fast and clear, but it does not need to behave like a public consumer product.

Permissions deserve special attention because recruitment data contains personal information. AppSheet provides authentication, application access controls, data access controls, and auditing options, but those platform features still have to be configured around a deliberate security model.² A low-code interface does not remove the need to design access boundaries carefully.

For a broader comparison of this architecture against fully custom software, see AppSheet vs Custom Build vs Hybrid.

What the system manages day to day

The architecture matters only because of the workflow it supports.

Vacancy-specific pipelines

The ATS maintains separate vacancy and résumé databases. Vacancies do not have to share one rigid funnel: different vacancies can use different pipelines, stages, and working rules.

The system tracks the résumé’s status in relation to a specific vacancy. That distinction preserves the real recruiting context instead of treating one global candidate status as the whole story.

Hiring teams, roles, and collaboration

Each vacancy can have a team assigned to it. Role separation controls what different participants can see and do.

Recruiters and hiring-team members can discuss a candidate inside the context of the vacancy. The conversation stays attached to the candidate-vacancy process rather than disappearing into a separate chat with no reliable operational history.

Communication and automatic templates

The ATS integrates with messengers and email. The team can use prepared email templates, including messages sent automatically by the workflow.

This connects communication to the candidate’s current stage. It also reduces the need to reproduce the same message manually while keeping the action inside the process history.

Status history and user activity logs

The system tracks changes to a résumé’s status for each vacancy. It also logs user actions and application changes.

That audit trail helps the team answer basic operational questions: who changed the record, what happened to the candidate, how the process moved, and where work may have stalled.

KPI tracking and lightweight gamification

Managers can set recruiting targets by week or quarter and compare them with actual results.

The system can show:

how many candidates were sourced or added;
how many résumés moved through each funnel stage;
how many interviews were completed;
how many people were ultimately hired;
performance by vacancy, recruiter, or hiring-team member;
progress against weekly and quarterly hiring targets.

Making targets and progress visible creates a lightweight gamification layer. The purpose is not to turn recruiting into a superficial leaderboard. It is to make expectations, funnel movement, and actual outcomes visible in the same place where the team works.

AI is useful, but it is not the foundation

The ATS includes AI-assisted résumé summarization. It gives the team a faster first-pass overview and makes relevant experience easier to scan. But it is not why the system has lasted for more than three years.

The durable value comes from the operating layer around it:

candidate data moves from HeadHunter into the internal workflow;
candidate data has a consistent home;
different vacancies can run different funnels;
vacancies have clear working teams;
roles and permissions reflect responsibility;
statuses drive the process;
communications and history remain attached to the work;
user actions are logged;
performance can be evaluated from the workflow.

AI improves one step. The system connects all the steps.

Adding summarization to a broken recruiting process does not repair it. Ownership, state transitions, data structure, and exception handling still have to work.

Why the first version could be built quickly

Roughly two months is a short timeline for a system that became daily business infrastructure. Three choices made that possible.

The process was concrete. The project was designed around one organization’s real recruiting workflow, not as a universal ATS for every company.
The stack matched the problem. The Chrome extension accelerated intake, AppSheet provided the interface, n8n handled automation, and MySQL carried the operational data.
The first version focused on workflow coverage. We supported the states, roles, data, and integrations the team actually used instead of reproducing every enterprise feature.

Fast delivery still creates responsibility. A two-month first version needs ownership, monitoring, careful changes, and maintenance if it is expected to run for years. Low-code reduces initial implementation time; it does not eliminate lifecycle work.

The result after more than three years

The strongest result is continued use.

The system:

remains part of daily recruiting operations;
contains more than 20,000 résumés;
imports résumé data from HeadHunter through a custom Chrome extension and n8n;
runs on a MySQL operational database;
centralizes vacancy work and candidate history;
supports different funnels and stages by vacancy;
supports role-based collaboration;
connects email, messenger, and automatic template workflows;
retains status history and user activity logs;
automates status-driven parts of the process;
provides weekly and quarterly KPI visibility;
adds AI summarization without making AI the operating model.

It also allowed the company to run this process without adopting a separate expensive enterprise ATS.

The economic effect includes avoided software cost and fewer manual steps across years of recruiting work. I do not have a verified total, so I will not turn that effect into fictional ROI math.

When a custom ATS is the right choice

This case does not mean every 300-person company should replace its ATS.

A custom or hybrid system becomes attractive when:

recruiting operations differ materially from standard ATS workflows;
important work keeps escaping into spreadsheets, email, and chat;
the company needs integrations or state logic that are awkward in the current product;
the process is stable enough to model;
someone can own the system after launch;
faster iteration is more valuable than buying a larger generic feature set.

An enterprise ATS is usually safer when:

the workflow is conventional;
the company wants mature functionality immediately;
regulatory, support, or procurement requirements favor an established vendor;
there is no internal owner for a custom operating system;
the business would rather adapt its process than maintain its own logic.

The decision should not be ideological. Custom is valuable when process specificity is real and the company is prepared to own the result.

Practical lessons from the case

Five lessons stand out.

Workflow fit beats feature count. The system lasted because it matched daily work, not because it tried to become the largest ATS.
Fast builds can become durable systems. Speed and longevity are compatible when the scope is concrete and the architecture matches the process.
Integration changes adoption. Automatic application intake removes a fragile handoff before recruiters even begin reviewing candidates.
AI should improve a step, not disguise a broken workflow. Résumé summarization is useful because it sits inside an operating system that already works.
The real proof is repeated use. Three years of daily operation says more than a polished launch presentation.

The larger takeaway

Good automation is not mainly about impressive AI demonstrations.

It is about systems that people can use every day, that preserve operational history, reduce unnecessary handoffs, and continue creating value after the excitement of launch has disappeared.

This ATS started as a focused two-month build. More than three years and 20,000 résumés later, it has become a practical example of what low-code, automation, and careful process design can achieve together.

If your recruiting workflow has outgrown its current tools and you want to evaluate a practical custom or hybrid approach, you can contact me through airat.top.