HireQwik Is Live on Product Hunt: What We Built

HireQwik is live on Product Hunt today. If you have arrived here from that page, this post is the longer answer to the question the tagline can only gesture at: what the thing actually does, what is genuinely shipped, and which numbers we are willing to defend.

We built it for a specific and fairly unglamorous problem. A single opening in an Indian campus or bulk drive can pull hundreds or thousands of applicants inside a week. The team on the other side is usually three to five people. Every honest solution to that gap is some form of “decide faster about more people without deciding worse,” and most tools in the category solve the storing and moving part rather than the deciding part.

The screening step, not another ATS

An applicant tracking system holds candidates and moves them between stages. It does not talk to three thousand of them.

That conversation is the step that actually filters, and it is the step that does not scale with headcount. A recruiter can do maybe twenty to thirty phone screens in a week before quality drops. So teams stop screening properly, fall back to resume keywords and college tier, and reject people who would have been good on a signal that was never a great predictor in the first place.

HireQwik sits in that gap. It does not replace your ATS and it is not trying to. It runs the screen: score the resume against the specific job description, invite the ones who clear the bar, hold the conversation, and hand back a ranked verdict a human can act on. We wrote up the full path from resume upload to shortlist if you want the stage-by-stage version.

What actually happens to one candidate

Four steps, in order, and each one is live in production today.

The resume is scored against that JD, not a generic template. The scoring rubric is derived from the job description itself, so a support role and a research role are not judged by the same criteria. Relevance matters more than volume here: fourteen unrelated years does not outrank three relevant ones.

The candidate books their own slot. No recruiter coordination. They get a link, they pick a time from the open slots, and the booking confirmation carries a proper calendar invite. Slots show real remaining capacity and close when they fill, which is why we describe throughput as up to 1,300 interview slots a day rather than a number that sounds better on a landing page.

An AI voice agent runs a fifteen to twenty minute structured conversation. Job-specific disqualifier questions fire first, so a candidate who cannot meet a hard requirement finds out in the first minute or two instead of at the end. The rest of the conversation is adaptive: it follows what the candidate actually says rather than reading a fixed script.

The recruiter gets a verdict with the evidence attached. Strong Go, Go, On Hold or No Go, with the recording, the transcript and per-question reasoning. If the JD is configured for it, the confident ends can be decided automatically so a human only opens the middle band. That middle band is real work and it needs an owner and a decision date, which we published separately today.

How a job description becomes a screening rubric

The step people ask about most in demos is the one between “here is my JD” and “the AI interviewed my candidates,” because that is where a generic tool usually reveals itself.

The job description is parsed into a structured screener document first: what the role actually requires, which of those requirements are hard disqualifiers, what an acceptable experience range looks like, and what a good answer to each question sounds like. The rubric the AI scores against comes out of that document, per role. A customer support opening and a research internship do not share a scoring template, because they do not share a definition of a good candidate.

Two consequences worth knowing before you try it. First, the disqualifiers you mark are the ones that fire in the first minute or two of the call, so marking too many turns a screening conversation into a quiz that ends early. Second, a rubric needs enough separate criteria to actually spread candidates apart. A rubric with one real criterion can only produce a handful of distinct scores, which bunches everyone into the middle where no threshold can separate them. We wrote that failure up in public after hitting it on a live role, including the part where the fix was ours to make rather than the customer’s.

You can also set an acceptable experience band per role, which is what stops a candidate with fourteen years of unrelated seniority outranking the person who can actually do the job.

The part I would argue about at a conference

Most screening tools score communication from a transcript. A transcript is what was said with the how stripped out.

So we run two evaluators. One reads the content of the answer. The other analyses the audio: pace, hesitation and filler rate, pronunciation, fluency level. Both have to agree before we recommend rejecting anybody, and the speech signal is deliberately asymmetric: it can lift a borderline candidate out of a rejection, but it cannot push a strong one down.

That asymmetry is a judgement call about where to put the risk, and it is the design decision I would defend hardest. In a market where a good candidate may be interviewing in their second or third language, a system that penalises an accent is not measuring what it thinks it is measuring.

Numbers we will stand behind, and the ones we will not

In July 2026, one customer campaign put 24,327 resumes through the system across nine open roles, and 1,074 of those became completed AI interviews. Across pilot campaigns we have run 1,099 interviews. In one evening, one drive screened 3,000 candidates in about two hours. On the HR side, the measured reduction in time spent per candidate against a manual phone screen was 89 percent. We published the month of usage data in full rather than summarising the flattering parts.

Now the other list, because a launch day is exactly when a company is most tempted to round up.

We do not publish an accuracy percentage for the model, because we have no held-out benchmark to back one and calibration is still ongoing. We do not claim a number of customers, because we have fewer than ten and they are pilots. We have no response-rate or no-show-reduction figure for the WhatsApp channel, because it went live in late August and has no measured outcome data yet. Anything you see us assert has a source behind it, and the things without a source are the things we stay quiet about.

The unglamorous parts we shipped anyway

Demos are won on the conversation. Deployments are won on what happens when something goes wrong at 9 AM on drive day, so a disproportionate amount of our engineering has gone into the boring half.

A running campaign can be stopped from the interface. Before that existed, halting a wrongly configured drive meant killing a process on the backend, which is not a thing you can ask a recruiter to do. Stopping also revokes the interview links that already went out, so a cancelled drive does not leave joinable links sitting in five hundred inboxes, and unused credits go back to whoever paid for them.

Candidates can reschedule, but not indefinitely. After three attempts within seventy two hours the slot picker locks and a human can reset it, because unlimited rescheduling by one candidate quietly consumes the slots everyone else is trying to book.

Every message we send a candidate is recorded against that candidate’s own row rather than only as a campaign total, so “did this specific person actually get the invite” is an answerable question. Capacity is enforced against live interviews rather than per slot, and a candidate arriving when the system is genuinely full gets a graceful response and another slot instead of a broken call.

None of that will ever appear in a launch video. All of it is what the difference between a demo and a deployment is actually made of.

What happens to a candidate’s recording

Fair question, and one we would rather answer plainly than bury in a policy page.

The interview is recorded because the recording is the evidence. A verdict a recruiter cannot check is a verdict nobody should act on, so the recording, the transcript and the per-question reasoning stay attached to the candidate and are what a hiring manager reviews when they want to challenge a decision. Recordings are held in cloud object storage, and production runs on a small set of dedicated machines rather than on a laptop under somebody’s desk.

Here is what we are not going to tell you: that we hold a particular compliance certification. We do not have one to name, and a launch day is precisely when a company is tempted to imply otherwise with a badge nobody reads carefully. If your procurement process requires a specific certification today, we are not the right vendor for you yet, and you should ask any vendor answering that question with a logo which audit it corresponds to and when it was last performed.

What we can commit to is the boring version of trust: the evidence behind every decision is visible to the person making it, and the candidate is told they are speaking to an AI interviewer rather than being made to guess.

Who this is probably not for

Small volumes and senior hiring. If you are filling four roles a quarter, a structured phone screen by a good recruiter beats anything we can do for you, and the setup cost will not pay itself back.

The economics and the design assume the other end of the range: hundreds or thousands of applicants per opening, where the alternative is not a better screen but no screen at all, and where the real comparison is against a resume filter that never heard any of these people speak.

Where it is honestly still rough

Three things, since a launch post that lists only strengths is an advertisement.

The system depends on the job description being written properly. A vague JD produces a vague rubric, and a rubric with only one real criterion cannot spread candidates apart at all. That is our defect to fix rather than the customer’s to work around, and we are not done fixing it.

Setup is not zero effort. Connecting a sheet, configuring the rubric and setting thresholds is an afternoon, not a click. We would rather say that than promise instant onboarding and have you discover the afternoon on your own.

And the screen is a filter, not a hiring decision. It tells you who is worth your time. Everything after that is still your team’s judgement, and any vendor telling you otherwise is selling you something we do not think exists.

Take the interview yourself

The most useful thing you can do today is not read about it. There is a live demo interview on the site: no signup, works in a browser with a microphone, runs about five minutes. It is the production voice agent and the production evaluation engine, not a scripted preview, and it emails you your own scorecard afterwards with the transcript and per-question evaluation.

Take it as a candidate would. Ramble a bit. Answer one question badly on purpose. Then read what came back and judge whether the evaluation is fair, because that is the only test of a screening tool that matters.

What we are asking for

Feedback on the specific things, rather than upvotes. Whether the verdict on your own demo scorecard matched your read of your own answers. Whether the evidence attached to a decision is enough for you to defend that decision to a hiring manager. Whether the setup steps make sense to somebody who has never seen the tool before.

That is the sort of comment that changes what we build next. The Product Hunt page is the place to leave it today, and we will be reading it all day.