We build a system that runs the whole candidate process in a single flow, from drafting the job ad through to the offer and the handover to onboarding. Whichever channel applications arrive through, they collect in a searchable pool, assessments are written on a shared form, and retention periods and data destruction are put on record.
In most companies recruitment starts with an urgent need: someone has left, orders have gone up, or a new line has opened. From that moment CVs arrive from four or five different places — the HR inbox, the job board's panel, WhatsApp, handed over in person through an acquaintance, and sometimes as a sheet of paper left at the gate. Each channel piles up somewhere separate and none of them sees the others. When the position is filled the pile stays where it is; six months later, when the same role opens again, the search starts from zero. Yet the person being looked for is often among the applicants from the previous round. Nobody finds them, because the record is not searchable and nobody owns it.
The second problem is that the process is invisible. Which candidate is at which stage, who interviewed them, why they were rejected and where the offer is waiting usually live in one person's head. The department manager says he liked that candidate; there is no such note in the HR record. Some candidates who came in for an interview never hear back at all, and every hiring round wears down the employer's reputation a little further. The headcount side is similarly vague: who requested the hire, which budget it was booked against and who approved it all turn into questions people have to go looking for later. The process cannot be tracked not because it is a bad process, but because it is written down nowhere.
An applicant tracking system (ATS) pulls this scatter into a single flow. The job ad is prepared in one place, applications land in the same pool whatever channel they came through, and records for the same person arriving from different channels are merged. Information from the CV is extracted into structured fields, so the pool genuinely becomes searchable: which machine they have operated, which district they live in, which shift they can work. The process is split into stages; which stage each candidate is at, who assessed them and on what grounds they moved forward are all on record. Interview notes go on a shared assessment form rather than into everyone's own notebook. When an offer is made the terms are recorded, and when the candidate accepts, the file is handed over to the onboarding side — that is, to the HR system.
We state two limits plainly on this page. First: CV parsing is a useful convenience, but it is not error-free; fields can be read incorrectly in free-form documents, so extracted information always stays editable and verification remains with a person. Second: software does not screen candidates out. Making automated scoring the decision mechanism on its own both rejects the wrong people and quietly perpetuates the bias in historical data; the system exists to shorten the list and to put the reasoning behind a decision on record, and the decision belongs to the hiring manager. A third matter should also be discussed from the outset: candidate data cannot be kept indefinitely. Which data is held for how long, and how consent is obtained, must be defined on the KVKK (Turkish data protection law) side; the system applies that decision and records the destruction.
Factories that run shifts, have high turnover and post vacancies almost every month. In these businesses the real gain is that past applicants accumulate in a searchable pool: when a new position opens there is somewhere to look before paying for an ad, and candidates who have already been interviewed can be contacted the same day.
Businesses recruiting for several departments at the same time. As the number of open roles grows, tracking where each candidate stands by email and spreadsheet stops being feasible. A staged flow prevents both candidates forgotten on hold and two colleagues separately calling the same person.
Set-ups where HR coordinates while department managers conduct the interviews. Writing assessments on a shared form means candidates are compared against the same criteria; decisions that would otherwise stay at the level of a verbal impression turn into a written rationale, and there is a record to look at when the question comes up later.
Businesses that are audited, receive large volumes of applications and are aware of their duties around personal data. CVs that have piled up in an inbox for years are an unmanaged heap; a pool with defined retention periods, recorded consent and traceable destruction reduces that risk in concrete terms.
Ad copy is drafted from a position template; the form on your careers page, on-site applications by QR code, email and records from job boards all land in the same pool. You can see how many applications came from each channel and which of them ended in a hire. The next round's channel budget is therefore decided from records rather than guesswork.
Applications from the same person across different channels merge into one profile, and past interviews, notes and correspondence sit on that profile. The pool is searchable on fields such as experience, machines operated, skills, district of residence and shift availability. Going back to a candidate you have already interviewed is both faster and cheaper than placing a new ad.
Contact details, education, experience and skills are extracted from incoming CVs into structured fields, with text recognition used on scanned documents. Every extracted field can be corrected and you can see which document it came from. The purpose of this step is to reduce data entry; it is not to assess or screen out the candidate.
The hiring request is raised by the department, and headcount and budget approval pass through a defined chain. For an approved position the process is split into stages: initial screening, phone call, technical interview, references and offer. You can see which stage each candidate is at and how long they have been waiting; stalled steps drop into a separate list.
The interview calendar is shared with the manager involved, and invitations and reminders go out automatically. Assessments are written on a shared form defined per position, and each interviewer completes their own score separately. Candidates are therefore compared against the same criteria, and when a decision is questioned later the reasoning is in the record rather than in someone's memory.
Offer terms are recorded, pass through the approval chain and are sent to the candidate; acceptance, rejection and negotiation steps are tracked on the same record. Unsuccessful candidates can be answered with templates and in bulk, so no position closes leaving people without a reply. Correspondence runs over email, SMS or WhatsApp and accumulates on the candidate profile.
A candidate who accepts is converted into an employee record and handed over to the onboarding checklist; paperwork, asset assignment and induction steps run from there, and the same information is not keyed in twice. Retention periods are defined per type of candidate data; when the period expires the record is destroyed or anonymised, and that action appears in the audit trail.
Together we map which positions open and how often, which channels applications come through, who conducts the interviews and how the decision is made. Blue-collar and white-collar hiring follow different flows in most businesses; making that distinction clear at the start is far cheaper than trying to build two separate systems later.
Stages, owners and assessment criteria are defined per position type. We write the form questions together: what the hiring manager actually looks at and the criterion written on the form must be the same thing, otherwise the form goes unfilled and the system is abandoned within the first few months. The headcount request and approval chain are also set up at this step.
The careers page form, on-site QR applications and the email channel are connected. How data can be transferred from job boards is examined platform by platform and the outcome is reported exactly as it is. Whether the old CVs you already hold are moved into the pool is decided after assessing their consent and retention status.
The system is first run end to end on a single open position: ad, applications, interviews, decision and handover. Real use shows which field is unnecessary and which step is missing, and the flow is simplified. We do not recommend opening it up to every position before the pilot is finished; the corrections that come out of the first round are usually the most valuable ones.
Retention periods and destruction rules for candidate data go live, and who can see which candidate is made explicit. The system is handed over to your team, with written guidance on how to define a new position type, how to update the forms and how to keep the pool clean. After that, maintenance and support run under an SLA.
It reads them; it does not screen them out. The system extracts contact details, education, experience and skills from the CV and can rank candidates against criteria you define, but we do not recommend leaving the rejection decision to software. Automated scoring carries both the reading errors of free-form documents and the bias in historical data, which it quietly perpetuates. The system's job is to shorten the list you look at and to put the reasoning behind a decision on record; the decision belongs to the hiring manager.
That depends entirely on the platform, and it is only fair to say so from the start. Some career sites offer integration to their corporate customers; others do not, or require a separate contract. On channels where integration is not possible the ad is posted manually and applications are brought into the pool by email or file transfer. During discovery we examine one by one what level of connection is possible with each platform and report the result exactly as it is; we do not present an integration that does not exist as though it did.
This is a legal decision and we do not set the period. Candidate data is personal data: which data is held for how long, how explicit consent is obtained and what the privacy notice contains are determined by your data controller and your lawyer. The system's job is to apply that decision — it holds the consent record, destroys or anonymises records whose period has expired, and leaves the action in the audit trail. CVs piling up indefinitely in an inbox today are, in this respect, an unmanaged risk.
This is very common in blue-collar hiring. A short application form can be completed on a tablet or kiosk at the gate or in the HR office, or opened on a phone by scanning a QR code. If paper applications continue, the form is scanned into the pool and its fields are extracted from there. The aim is not to force candidates to use an app, but to turn every application, however it arrives, into a single searchable record.
The order varies by company. If your hiring volume is high and applicant tracking is your real pain point, starting with the applicant tracking system makes sense; it also works on its own. But if the personnel file, documents and leave tracking for the person you hire are still scattered, the benefit stops halfway, because there is nowhere to hand over to. Our general advice is to secure the employee record first and connect applicant tracking straight afterwards; we decide the right order during discovery by looking at your current workload.
Position templates and a headcount approval flow; a single candidate pool that gathers every channel, with searchable candidate profiles; editable fields extracted from CVs; staged process tracking and lists of waiting candidates; interview scheduling with shared assessment forms; offer and rejection communication; onboarding handover; retention periods and destruction records. Everything produced — source code, database and documentation included — is yours.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We give every rack and bin in your warehouse an address and record every movement by barcode. From goods receipt to put-away, from pick routing to dispatch checks, the flow runs on handheld terminals; underneath the quantity figure in your ERP we add the physical location of the goods and who moved them, and when.
Details →We capture incoming, in-process and final inspection records on a tablet on the shop floor; when a non-conformance appears we quarantine the goods, start the corrective and preventive action (DÖF / CAPA) flow and follow it through to closure. Measurements, certificates and approvals accumulate by batch, so you go into an ISO 9001 audit with a file that is already prepared rather than one assembled retrospectively from binders.
Details →Working from your bill of materials (BOM), we calculate which material is needed, in what quantity and by when; then we deduct stock on hand, open orders and lead times to produce dated order proposals for purchasing. With the MRP II layer we also test the same plan against machine capacity and labour.
Details →We build the software a dealership, a showroom and an authorised service centre run their own business on: vehicle or product stock, the showroom sales process, service appointments and work orders, warranty claims and integration with manufacturer-side systems come together in one structure. Your existing accounting package stays where it is, and the source code is yours.
Details →For companies whose sales run through dealers, distributors and solution partners we build channel software: partner records and tiering, target and commission calculation, lead sharing and conflict prevention, marketing collateral, and training and certification tracking are brought together in one place.
Details →We build a system that runs the work of your field reps from a phone: route and visit plans, mobile ordering, in-field collections, shelf and competitor photos and target tracking all come together in a single app. The app also works without an internet connection and synchronises by itself once the connection returns.
Details →
