What we are building next, and what it is waiting on

The roadmap is grouped into three horizons. Near is what is in active build now and expected in the current release cycle; those items also appear on the status board badged as in build. Next is what has been specified and prioritised but not started. Later is a stated direction with the shape agreed and the detail open.

Items move between horizons in both directions and the movement is published. An item sliding from near to next is more informative than an item arriving on time, because it usually means we found the constraint that the original estimate missed. Where that happens, the roadmap says what the constraint was.

The largest input is what customers and trial accounts actually ask for, weighted by how many desks the request would affect and by how much of the working day the gap costs. A request from one account that would save that account ten minutes a week loses to a request from a dozen accounts that removes a manual step from every submittal.

The second input is what we can see. Where a workflow is abandoned halfway, where an import fails, where a screen is opened and immediately left. Those signals are frequently more honest than the feature requests, because people ask for the thing they can imagine rather than the thing that is costing them.

The third input is the anti-position. Surhires is recruitment software: candidate relationships, outbound sourcing, client submittals and the placement pipeline through to the first invoice. It is not an HRIS, a payroll system, a background-check provider or an assessment platform. Requests that would turn it into one of those are declined and recorded as not planned with the reason, which is more useful to a buyer than silence.

This is the part of a roadmap that vendors usually leave out, and it is the part that explains the ordering. Four dependencies sit outside engineering entirely, and no amount of development effort moves them.

Job board integrations require admission to each platform's partner programme. Application, technical review and approval sit with the platform, on the platform's timetable, and we will not ship a scraper as a substitute because the account suspension that follows lands on you rather than on us. US SMS sending requires brand and campaign registration with the carriers, which is a compliance process with its own queue; multi-channel sequencing is behind it. WhatsApp outside the India market requires message template approval from Meta, template by template, and a template rejection is a rewrite rather than a bug fix. And general availability itself is gated on an independent third-party security review, which is a scheduled engagement with an external firm whose findings we then have to close.

Where an item is blocked, the roadmap names the blocker rather than showing a vague date. A blocked item with a named blocker is something you can reason about. A blocked item presented as an estimate is not.

Every item passes the same gates before it ships, and the gates are the reason a date would be a guess. First, the workflow completes end to end for every role that needs it, including the roles that only touch it once a month. Second, permissions are enforced across desks and across tenants, which is the gate that most often sends a feature back. Third, telemetry reports success and failure without a support ticket. Fourth, the failure path is defined and visible to the user.

For anything that touches candidate personal data there is a fifth gate: the consent basis, the retention behaviour and the export and erasure path all have to work before the feature is switched on, not after. That gate is why the compliance surfaces are sequenced where they are. It is easier to build consent capture alongside the features that depend on it than to retrofit it across a product that already holds the data.

Tell us what the gap costs you rather than which feature you want. A request that describes the workflow, how often it happens, who does it and what it currently takes is worth several requests that name a feature, because it frequently turns out that the underlying problem has a cheaper solution than the one requested.

Trial accounts and customers can raise requests directly, and every request gets an answer: planned, not planned, or already possible in a way that was not obvious. Not planned is a real answer here and it comes with the reason. A vendor who never says no to a feature request is either building a product with no shape or is not answering.

Partners have a second route. Implementation consultants and RPO advisers see failure patterns across many deployments rather than one, and the partner programme includes a channel for that signal specifically. It is one of the reasons the programme exists.

The near horizon is the Wave 1 in-build set: the client portal, talent pools, data import, the Chrome extension, the Bullhorn migration path, consent and retention, the EEO reporting firewall, the pay transparency validator, source-of-hire attribution, client relationship scoring, post-offer engagement, interview kits, candidate nurture sequences and the job description generator.

The next and later horizons hold the four planned items: the AI notetaker, which follows the voice interview beta because it records people who have not agreed to anything; the AI sourcing agent, constrained by what the candidate platforms permit; multi-channel sequences, behind carrier registration; and the MCP server, which waits on the permission model, because an agent interface to a candidate database is an exfiltration surface if the scoping is wrong.

Each of those has its own page written in the future tense, with the constraint explained rather than summarised. If one of them is why you are considering Surhires, read the page and then weight it as a plan.

Slippage is published on this page and, once the product is generally available, in the changelog. The entry says what moved, which horizon it moved to and what caused the move. We do not quietly re-order the list and hope nobody had a screenshot.

The one thing that never happens in response to a slip is a status badge upgrade. A feature does not become shipping because the quarter ended. It becomes shipping when it passes the gates, and if that is a quarter later than intended, the roadmap says so and the status board keeps saying in build.