Every feature area, with its real build status

The working core of the product is live. The candidate database holds structured profiles with normalised skills, seniority, location, notice period and salary expectation, plus typed custom fields, with an activity stream on every record. Applicant tracking runs a configurable stage machine with submittals as first-class objects and a fixed disposition list, and the pipeline view computes time-in-stage and surfaces the exceptions rather than the totals.

Around that core, resume parsing, bulk resume import, AI candidate matching and AutoShortlist are all shipping. So are interview scheduling, offer letters, assessments, the candidate blacklist, the HR conversion path that turns a placement into an employee record, and the iOS and Android recruiter app built on Capacitor. WhatsApp is live for the India market on the Business API, which is a market-specific statement rather than a global one.

AI interview calls ship today in a controlled beta. That word is doing real work: the capability is in production and customers are using it, but it is enabled deliberately rather than switched on for everybody, because a system that telephones candidates has failure modes that only appear at volume.

Several areas work now but are honestly described as partial, because the version that ships is narrower than the version the feature page describes in full. Candidate communication and email cadences are the clearest example: sending, templating and threading work today, and the sequencing depth, branching and reply classification are landing across the Wave 1 release.

Placement invoicing raises an invoice against a placement today and is being extended on the rebate, guarantee and multi-currency side. Candidate scorecards capture structured interview feedback and are gaining panel-level comparison. Analytics and reporting produces the dashboard set today and is being extended with the deeper attribution cuts. Multi-board job posting publishes to the connected boards it names and is adding the rest. Duplicate candidate detection runs on import and is being extended to run continuously.

Partial is the badge most likely to be quietly upgraded to live by a marketing team. It is not upgraded here. If you are evaluating on one of these areas specifically, the feature page for it names what works now and what does not, and that is the paragraph to read.

In build means engineering is working on it and it is not usable today. The client portal, which gives a hiring manager a read-only shortlist view without consuming a seat, is in build. So are talent pools, the data import tooling, the Bullhorn migration path and the Chrome extension for user-initiated capture.

The compliance surfaces are in build as a group: consent capture and retention windows, the EEO reporting firewall that keeps demographic data out of the hiring record, and the pay transparency validator that checks a posting against the disclosure rules of the jurisdictions it is going to. Source-of-hire attribution, client relationship scoring, post-offer engagement, remote talent sourcing, time-zone scheduling, interview kits, candidate nurture sequences and the job description generator are also in build.

None of these should be counted as capability in a scoring matrix today. If one of them is decisive for you, the honest answer is to ask for the current build state and a date, and to weight the answer accordingly rather than treating the feature page as a delivery promise.

Four things are planned with no build under way: the AI notetaker, the AI sourcing agent, multi-channel sequences and the MCP server. Each has a page on this site, each page says in its first paragraph that the feature does not exist, and each explains what has to be true before it can be built.

That last part matters more than the plan. The notetaker follows the voice beta because it records people who are not your customers and have not agreed to anything, across jurisdictions with different consent rules. The sourcing agent is constrained by what the large candidate platforms permit in their terms of service, and building a covert version would put your seat licences at risk rather than ours. Multi-channel sequencing waits on carrier registration for SMS. The MCP server waits on the permission model being right, because an agent interface to a candidate database is a data-exfiltration surface if the scoping is wrong.

The internal feature audit was produced by grepping the codebase, and it found more capability than the product could honestly claim. That is the normal outcome of such an exercise, and it is where most vendor feature lists come from. The rule we adopted in response is that file existence is not production readiness.

A capability is only badged as shipping when four things hold. The workflow completes end to end for the roles that need it, not just for an administrator. Permissions are enforced on it, so the feature does not leak data across desks or tenants. Telemetry exists, so we can see it working or failing rather than waiting for a support ticket. And the failure path is defined: what the user sees when the third-party service is down, when the parse fails, when the calendar rejects the hold.

Anything missing one of those four is partial or in build, however complete the code looks. This costs us feature-count comparisons against vendors who count differently. It is the trade we made deliberately, and this page is where it is visible.

Take your requirement list and mark each line against the four states rather than against a yes or no. A requirement met by a shipping feature is a fact you can test in the trial. A requirement met by a partial feature needs a specific question about which part ships. A requirement met by an in-build feature is a bet on a date. A requirement met by a planned feature is not met.

Then do the same to every other vendor on your shortlist, which is the harder half of the exercise, because most will not give you the vocabulary to do it. Ask them which features on their pricing page are generally available today, which are in limited release, and which are on the roadmap. The answer, and the speed of the answer, tells you a great deal.

Badges move in one direction most of the time, from planned to in build to shipping, and each move is a changelog entry once the product reaches general availability. A move in the other direction is rarer and more important: a feature pulled back from shipping to in build because a failure mode appeared at volume.

We publish those too. A vendor who never regresses a status badge is either extraordinarily lucky or is not using the badges honestly. The roadmap page explains how items are chosen and what they are waiting on; the changelog records what actually changed and when.