The client and the problem
The client is a recruitment agency that had grown well past what Excel could handle. Every job opening lived in its own spreadsheet. Every candidate resume sat in a folder somewhere on a shared drive. Status updates lived in people's heads.
The owner's day looked like this: a client calls asking for an update on a role. He doesn't know the answer. He pings a recruiter. He waits. He calls the client back twenty minutes later, if he's lucky.
Multiply that by every open role, every client, every day. The agency wasn't short on good recruiters or good candidates. It was short on a system that could tell the owner what was actually happening across the business, in real time.
That's a recruitment digital transformation problem, not a hiring problem — a system that tracks things automatically and puts the answer in front of the owner before the client finishes asking.
The constraint that shaped the build
Here's where most vendors would have pushed the client toward a standard cloud ATS. We couldn't, because of one non-negotiable requirement: the resumes could not go to the cloud.
Over years of operating, the agency had built up more than 1TB of resumes. That archive is the business — years of candidate relationships, client history, and sourcing work. The owner wasn't willing to hand that over to a third-party cloud platform, full stop. Data sovereignty wasn't a checkbox for him. It was non-negotiable.
And this wasn't their first attempt at fixing the problem. The client had already tried an off-the-shelf ATS once, and spent six months porting all their data into it, only to find it didn't help the actual work. The tool needed constant technical setup and leaned on a dedicated IT person to keep it running right. So when we offered the fast path again, setting up an existing ATS on their own infrastructure, they'd already lived through why that fails for them. What they wanted this time was full control of both the application and the data: a system they owned outright, not one they had to depend on a vendor or a specialist to operate. That is what moved the project from configuring an off-the-shelf tool to building one from scratch: more work upfront, in exchange for a system that fit their process and needed no babysitting.
Most ATS products assume your data lives in their cloud. That assumption was the actual blocker standing between this agency and every recruitment software vendor that had pitched them before us. So the brief wasn't "build an ATS." It was "build an ATS that respects a hard no on cloud resume storage, and still gives us modern search, screening, and reporting."
Our approach: from manual process to AI-assisted automation
We don't jump straight to AI on a project like this. We follow a ladder, and skipping steps is how automation projects fail quietly six months in.
- Step 1 — Map the manual process. We sat with the recruiters and the owner and wrote down what actually happens today: how a resume comes in, how a job opens, how a candidate moves through stages, how a client gets an update.
- Step 2 — Turn it into a documented SOP. The informal, in-someone's-head process became a written standard: who does what, in what order, with what inputs and outputs.
- Step 3 — Turn the SOP into a workflow. Each SOP step became a defined stage in software — a job opening has stages, a candidate has stages, an update has a trigger.
- Step 4 — Automate the workflow. Once the stages were defined, we removed the manual labor from moving between them: metadata extraction, status syncing, and report generation all became automatic.
- Step 5 — Add AI where a decision has to be made. Only then did we add AI — for parts that need judgment, like screening a resume against a job description, not for parts that are just data movement.
This order matters. AI applied to a process nobody has documented just automates the chaos faster. Documenting first, automating second, and applying AI last is what makes the AI outputs reliable — the system already knows what "correct" looks like before it starts making calls.
The hybrid architecture: local resumes, cloud everything else
The technical answer to "keep 1TB of resumes off the cloud but still make them searchable" is to split what stays local from what goes to the cloud.
What stays on-premise
The resumes themselves — all 1TB and growing — live on a local system at the agency's premises. They never leave. No upload, no sync, no cloud backup of the raw files. This is on-premise recruitment software in the truest sense: the sensitive asset never crosses the wire.
What syncs to the cloud
A local script reads each resume, pulls out the metadata — skills, experience, contact details, job history — and sends only that extracted metadata to a cloud search database. The resume file stays put. Only the searchable summary of it travels.
What the team actually uses
A custom frontend and a mobile app sit in the cloud and talk to backend APIs. Recruiters search, filter, and manage candidates through that metadata layer. When someone needs the actual resume file, the system pulls it from the local vault — the cloud layer is a directory, not a copy.
This is the kind of split we design through custom software development when a client's data rules don't fit a standard SaaS product. The architecture bends around the constraint instead of asking the client to compromise on it.
Have a data constraint that's blocked you from automating?
If a vendor has told you "just put it in the cloud" isn't optional, talk to us about the alternative.
What we built
AI-based applicant screening
Once metadata sync was in place, AI resume screening became possible without touching a single raw resume file in the cloud. The system reads the extracted metadata against a job's requirements and ranks applicants for the recruiter to review — a first pass, not a final decision. A recruiter still makes the call. The AI just removes the hours of manual comparison that used to sit in front of that call.
Job Opening Management for the client's own clients
The agency's clients — the companies hiring through them — needed their own visibility into open roles. We built Job Opening Management so the agency could track every role its clients had asked it to fill, with status, stage, and candidate pipeline attached to each one.
A Kanban-view dashboard for the whole pipeline
The owner now sees the entire business on one screen: every open role, every candidate stage, every client, laid out as a Kanban board. This is where the "twenty minutes to find an answer" problem actually got solved — the answer is already on the screen before the phone rings.
Full applicant tracking
Every candidate's journey — sourced, screened, submitted, interviewed, placed, or rejected — is tracked end to end. That's what makes a custom ATS a system of record instead of a bigger spreadsheet.
A mobile app
Recruiters aren't always at a desk. The mobile app gives them the same pipeline and candidate view on a phone, so a status update doesn't wait for someone to be back at their laptop.
Migrating years of Excel and files into the new system
None of this works if the old data stays trapped in spreadsheets. We migrated years of candidate records, job history, and file references into the new system, so day one on the new ATS was a continuation, not a restart.
The results
The agency went from Excel and file folders to a fully digital operation. That sentence undersells how much friction disappeared.
And it happened fast. From the first conversation to a fully installed system and completed user acceptance testing, the project took two months. The client's feedback on the result was positive.
The owner can now follow up on any candidate or role in two clicks, not a phone call and a wait. He can generate a status report for a client in one click instead of assembling it by hand. When a client calls asking "where are we on this role," he answers on the call — he doesn't need to call back.
Recruiters spend less time on status chasing and updating spreadsheets, and more time doing the part of the job that actually needs a person: talking to candidates and clients.
There's a second-order effect worth noting. Twenty-two years in recruitment doesn't only make someone a demanding client — it makes them a well-connected one. Since the build, the owner's relationships with senior leaders and business owners have opened doors for us into new industries, where the same pattern keeps appearing: years of accumulated data, a reason to keep it in-house, and a manual process waiting to be automated.
Why this matters if you're evaluating a partner
If every vendor conversation starts with "upload your data to our cloud," you're not being offered a choice — you're being offered their product's default. Fine if your data has no sensitivity attached. A dealbreaker if it does.
The lesson here isn't "AI recruitment automation requires the cloud." It's that the constraint should shape the architecture, not the other way around. A local vault for sensitive data, a cloud layer for searchable metadata, AI applied only where judgment is needed — that combination works for recruitment, and for any business sitting on years of data it won't put on someone else's server.
We work through this same reasoning in every AI consulting engagement: what has to stay put, what can move, and where AI actually earns its place in the workflow instead of being bolted on for the sake of it. If the answer involves machine learning on top of your own data, our AI and machine learning team builds that layer too.
Running your recruitment business on spreadsheets?
Tell Maddy what your process looks like today — we'll tell you what a custom ATS built around your constraints would look like.