Services
AI Solutions
TL;DR: The discovery methodology from Part4 produced 24 specific problems across 7 clusters, with a totalestimated cost of 150,648 PLN per year — 85% of which is opportunitycost, not direct time loss. This post walks through all 7 clusters: whateach problem looks like in practice, why Recruitee cannot solve itstructurally, and what the financial breakdown behind each cluster meansfor the decision ahead.
The ATS problems we found fell into two cost categories: direct costs(time your team actually burns doing manual work) and opportunity costs(the harder-to-measure downstream consequences). The full picture,across all 7 clusters, looks like this.
The methodology behind these numbers is in Part4. The cost model was firstintroduced in Part 2 in monthly form. What follows is the annualview with problem counts added.
Two things worth naming before the deep dives. Cluster 1 aloneaccounts for 101,520 PLN/yr — 67% of the total — despite containing only4 of the 24 problems. And 85% of the total (128,124 PLN/yr) isopportunity cost, not direct time loss. That composition matters for howthe numbers should be read, and for what it would take to justify thebuild. The next section covers the three clusters where that story ismost concentrated.
On a typical morning during an active hiring period, someone opensthe tool to check the pipeline before a planning meeting. Thetime-to-hire metric reads 23 days. Manual tracking shows the real numberis 31. That is an eight-day gap between what the tool reports and whatthe process actually does.
The calculation logic counts calendar days from job posting.Appunite’s pipeline does not start the clock there. What matters is fromfirst candidate interaction, or from the stage transitions that reflectactual movement through the funnel. Those two definitions producedifferent numbers. There is no configuration option that changes theunderlying logic. It is hardcoded — built for the median case, and themedian case defines time-to-hire differently than we do.
The other three problems in this cluster compound this. The hirecount metric shows 0% regardless of actual completed hires — it is ametric that is visibly broken with no workaround other than ignoring it.Cost-per-hire requires combining Recruitee data with payroll data thetool cannot access, so the team either skips the metric or exports rawdata and calculates manually. Reports do not update in real time, somorning pipeline data does not reflect the previous evening’s activityduring active hiring periods.
Now, the 23-day discrepancy had been there for months before theaudit. Every planning meeting, every hiring retrospective, everyheadcount conversation was built on the wrong number.
Cost: 101,520 PLN/yr total — 1,728 PLN/yr direct (time manuallycross-checking and correcting reports) and 99,792 PLN/yropportunity.
That opportunity cost figure carries an assumption that must be namedexplicitly. It rests on the estimate that 50% of failed hires trace backto decisions made on inaccurate reporting data. At Appunite’s hiringvolume and cost-per-hire, one additional failed hire per yearattributable to bad data produces the bulk of that number. I think theattribution is reasonable. Inaccurate pipeline data does affectheadcount decisions, and headcount decisions do affect hiring outcomes.But I cannot prove the exact causal chain. At 0% attribution, the ROI onthe entire build project moves from +75% to -74%. That is the mostconsequential single number in the cost model, and every figure thatfollows should be read with that in mind.
The interview ends. The interviewer goes back to their desk.Somewhere between two hours and the following morning, they write theirnotes from memory. The feedback form is an open text field. No template,no scoring rubric, no standard dimensions to respond to. One interviewerwrites three sentences. Another writes three paragraphs. A third usesbullets that map to nothing the next interviewer used for the samecandidate.
When the hiring team meets to decide between two finalists, they arecomparing things that cannot actually be compared. The notes exist. Thesignal from the conversation — the candidate’s explanation of a systemdesign decision, the specific way they navigated a difficult scenario —mostly does not.
This is not a failure of the interviewers. It is what happens whenthe feedback structure is a blank text field. There is no recording, notranscript, no structured capture of what was said. After each technicalconversation, what was discussed lives only in the interviewer’s memoryuntil they write it up, and degrades from the moment the call ends. Whenmaking a final decision between two strong candidates, there is nostructured view showing both side by side. Decision-makers work fromfragmented notes in different formats written at different times.
Recruitee’s feedback model was designed for the use case where notesare sufficient — generalist roles, standard interview formats, lowertechnical depth. For evaluating senior Elixir engineers on architecturedecisions, system design thinking, and communication quality inclient-facing contexts, an open text field is not a data structure.These are not Recruitee limitations in the defect sense — they aredesign boundaries. No configuration of the existing fields producesstructured, comparable, searchable interview data. The product was notbuilt for this, because most of its customers do not need this.
Cost: 24,636 PLN/yr total — 4,680 PLN/yr direct (20–30 minutes perinterview for post-interview writeups, multiplied by interview volumeand hourly rate) and 19,956 PLN/yr opportunity (lost signal leading toworse offer acceptance rates and early attrition outcomes, at aconservative estimate).
A new senior Elixir role opens. The team remembers that six monthsago, they interviewed someone strong — the timing was wrong, headcounthad not been approved. That candidate exists in the system. Theirinterview notes exist too. But there is no way to search for “candidateswith strong Elixir scores, passed over for timing rather thanperformance.” The data is in a text field. It is not queryable.
So the recruiter starts from zero: same job boards, same outreach,same channels. A candidate the team already knew was qualified goesuntouched, because there is no path from “new role opens” to “here arethe people we already evaluated.”
The four specific problems: no structured competency scoring, sothere is no aggregate view across interviewers and no way to comparecandidates systematically; past candidates are not surfaceable for newroles, because the data exists in notes rather than in queryable fields;sourcing is role-level, not competency-level, so there is no way totarget outreach based on documented profiles from prior interactions;and technical assessment results from external tools cannot be attachedto the candidate record in a structured way — they live in email threadsor spreadsheets, disconnected from the candidate’s history.
Recruitee was designed for companies hiring generalists at moderatevolume, where each candidate interaction is relatively self-containedand the talent pool is large enough that re-sourcing from scratch ismanageable. Senior Elixir engineers are a small community, and therelationship with a candidate who was good-but-wrong-timing has realvalue months or years later. The tool’s data model was never built tosupport longitudinal candidate relationships because most of itscustomers do not need that.
Cost: 10,092 PLN/yr total — 6,036 PLN/yr direct (recruiter time onmanual sourcing steps that a competency-indexed system would reduce) and4,056 PLN/yr opportunity (cost of re-sourcing from scratch rather thansurfacing known, pre-qualified candidates).
The seven clusters share a single structural root cause: Recruiteewas built for the median case, and Appunite is not that case.
The median case looks like this: a company with moderate hiringvolumes, generalist roles, a standard funnel structure, standardreporting needs, and standard GDPR handling. That product iswell-designed for that market. The calculation logic, the feedbackmodel, the sourcing structure, the compliance handling — all of it makessense for an SMB hiring across a range of roles from a large talentpool.
Appunite’s use case differs on four dimensions. Hiring volume is lowand the quality bar is high — the tool was optimized for throughput, butwhat matters here is depth of evaluation at each step. The talent poolis narrow — senior Elixir engineers are a small community whererelationship tracking over time carries strategic value. Technicalevaluation is complex in ways a standard notes field cannot accommodate.And data ownership is strategic — cross-referencing hiring outcomes withactual engineer performance post-hire requires owning the data model,not renting access to it.
This is a product-market fit problem, not a product quality problem.A tool built for one market, applied to a different market. Thestructural limitations in all seven clusters are features of whatRecruitee built — they just do not serve Appunite’s specific usecase.
There is a second thing worth naming here, less comfortable than thestructural analysis. When we ran the audit, several of the workaroundshad become invisible. Manual calendar coordination. Memory-basedinterview feedback. The 23-day time-to-hire figure. These were notexperienced as problems — they had become “how hiring works.” One smalladaptation at a time, the friction had accumulated until it was just thetexture of the process. The team was not oblivious. The friction hadsimply stopped registering, which is a different thing, and the auditwas what made it visible again.
This article is not a Recruitee review. It is a case study in whathappens when a mature, specific process meets a generic tool. Therecruitment software issues we found are a specific version of a moregeneral pattern. If you manage a technical team and use any SaaS for aprocess that is central to how you work, the pattern is probablyfamiliar.
The thing that made our audit productive was not the software we wereauditing — it was the questions we asked. Three in particular cutthrough the normalized friction.
Are there metrics in your tool you cannot customize, where thevendor’s definition does not match what your process actually needs tomeasure? In our case, “time-to-hire” meant one thing in the codebase andanother in our actual pipeline. We did not know the gap was eight daysuntil we measured it directly. If you are using tool-generated metricsto make decisions — headcount, capacity planning, team sizing — it isworth verifying that the calculation matches your process definition,not just the general-purpose one.
Are there workflows you cannot modify, where the tool’s structureforces your process to conform to its logic? The inelastic funnelstructure and the fixed feedback form both fall here. The cost is notjust friction — it is decisions made on data shaped by the tool’sconstraints rather than by what your process actually requires.
Is there data in your tool you cannot cross-reference, where theinformation exists inside the system but cannot be queried in the waysyour decisions require? Past candidates, assessment results, competencyscores, longitudinal outcome data — these exist in our system as text infields that cannot be searched or combined. The data is there. It isjust not accessible in a useful form.
If the answer to any of these is yes, the SaaSTax framework applies. The question is not whether your tool isgood. The question is whether it is right for your specific use case —and whether the gap has become invisible enough that you have stoppedasking. You’ll find a ready-to-useevaluation template here
The audit is complete. The numbers are as honest as they can be giventhe constraints.
24 problems across 7 clusters. Total estimated cost: 150,648 PLN/yr —22,524 PLN/yr in direct costs that show up on timesheets, and 128,124PLN/yr in opportunity costs that require attribution assumptions toreach. Cluster 1 alone accounts for 67% of the total, and itsopportunity cost rests on the assumption that 50% of failed hires traceback to inaccurate reporting data. That assumption is reasonable. Itcannot be proven.
Against a build budget of 86,000 PLN, the evidence raises a questionit cannot fully answer. Direct savings alone produce a -74% ROI.Including opportunity costs produces +75%. The case only works if ameaningful fraction of those opportunity costs are real — and thelargest portion depends on a single attribution assumption that can beargued, not verified.
That question — whether the assumptions hold, and whether the costevidence actually justifies building — is what the next post addresses.The evidence is on the table. The verdict is not.
