Cross-border candidate data
CVs are personal data under GDPR, moving between jurisdictions, held on behalf of clients who have their own compliance obligations.
WOLKK ATS Cloud
The system we run our own business on.
- Client
- WOLKK (internal)
- Scope
- Full product design, development and operation of a recruitment platform
- Environment
- Lovable.dev, in production, in daily use
- Status
- WOLKK's sole ATS since launch, continuously extended
Why this case study exists
Every consultancy claims expertise in something. The harder question is whether they'd bet their own operation on it.
We tell clients that a Lovable build can be a serious production system if it's engineered like one, with real access control, real data protection, real structure. That's a strong claim, and it deserves more than a slide.
So here it is: WOLKK ATS Cloud is the only applicant tracking system we use. Every candidate we place with a European client goes through it. It was built on Lovable.dev, by our own engineers, and it runs our business.
The problem we had
Outsourcing is a recruitment business with an unusual shape. We source engineers across Southeast Asia and place them with clients in Germany and other countries. That means:
Visibility, but not all of it
A client should see the candidates we're presenting. They should not see our sourcing pipeline, our internal notes, our cost structure, or anyone we're presenting to someone else.
Anonymisation as a working requirement
Presenting a candidate before the client commits means presenting the skills without the identity. That's not a nice-to-have.
Multiple clients, one role
Standard agency ATS products model one job to one customer. Ours doesn't work that way.
We tried to live with generic tools. The result was the familiar one: an ATS that handled some of it, spreadsheets that handled the rest, email that handled the parts nobody wanted to admit to, and no single place where the truth lived.
The available products would have required us to change how we work. Given that how we work is the business, that was the wrong trade.
What we built
A pipeline that matches ours
Drag-and-drop kanban across our actual stages, applicants, screening, shortlist, technical challenge, client presentation, interview, offer, signed. Configurable per role, because a senior backend hire and a junior QA hire don't follow the same path.
Jobs that can carry multiple clients
Requisitions support multi-customer association, internal assignment, salary and cost tracking, start and close dates, and archival. This is the agency-specific modelling that off-the-shelf systems don't do.
AI CV parsing
Uploaded CVs are parsed automatically for name, contact details and structured data, with confidence scores surfaced to the recruiter, including correct handling of Indonesian phone number formats, which no international tool gets right. The recruiter confirms before anything is committed. The AI removes the typing, not the judgement.
In-browser CV anonymisation
Recruiters redact identifying information and generate a client-ready version without the document ever leaving the platform or passing through a third-party editor. This is the single most-used feature in the system.
TalentCloud, the client portal
Our clients get their own branded environment to review presented candidates, leave structured feedback, and follow progress on their roles. Visibility is controlled explicitly by the recruiter: a candidate becomes visible when we decide they do, and never before.
Role-based access with database-level enforcement
Admin, recruiter and viewer roles, with row-level security enforced in the database rather than the interface. This is the part we take most seriously, and it's the part clients ask about first.
Collaboration built into the record
Comments, @mentions and activity logging on candidates, so context lives on the candidate rather than in someone's inbox.
Templated communication with an audit trail
Email templates with dynamic variables, shared and personal, with logged activity, so we can always reconstruct what a candidate was told and when.
A dashboard that reflects reality
Active roles, recent movement, deduplicated activity feed, and the metrics we actually manage against.
Engineering it as a production system
Building this in Lovable meant deliberately importing the discipline that an AI development environment doesn't impose on you:
Authorisation at the data layer
Every access rule is enforced in the database with row-level security. Nothing depends on the interface hiding a button. A recruiter cannot query another recruiter's confidential data, and a client cannot query anything beyond what has been explicitly released to them, regardless of what request they construct.
Privacy by design, because we're the data processor
Anonymisation as a first-class feature. Defined retention. Access scoped to necessity. Our clients' compliance teams ask questions about how we hold candidate data, and we're able to answer them precisely.
Structure that survives iteration
Consistent patterns, consolidated logic, components organised so that both our engineers and the AI tooling can work in the codebase without collateral damage. An AI-built system degrades fast without this. With it, it doesn't.
Mobile as a real requirement
Our recruiters work from phones, and so do our clients' hiring managers. Responsive layouts throughout, including a kanban board that works on a small screen, which is harder than it sounds.
What it changed
The fragmentation is gone. Jobs, candidates, clients, communication and history live in one system, and there is no second place to check.
Placement moves faster: parsing removes data entry, the pipeline is visible at a glance, and client feedback arrives through the portal instead of a thread with four people on it.
Our clients see a difference too. Presenting candidates through a branded portal with anonymised, consistently formatted CVs is a different experience than an email with attachments, and for a company positioning itself on German-standard process, the tooling is part of the argument.
And because it's ours, it changes when we need it to. New requirement, new module, not a support ticket to a vendor and a place in someone else's roadmap.
The part that matters for our clients
We didn't build this to sell it. We built it because we needed it.
But it's the reason we can speak with authority when a client comes to us with a Lovable prototype and asks whether it can be trusted with real data. We've done the security work, the structural work and the compliance work on our own system, in the same environment, under the same constraints, and then lived with the result every working day since.
That's a different kind of credential than a case study about someone else's software.
Have an AI-built tool you're relying on more than you probably should? We'll audit it and tell you honestly where it stands, the same review we ran on our own.