Custom Software Development for Recruitment Agencies

When your ATS or CRM actually becomes the problem

Most agencies that come to me convinced they need custom software development have a configuration problem, not a platform problem. The two feel identical from the inside - the system isn't doing what you need, consultants are working around it, and the pain is real. But the causes are different and so are the fixes.

The most common pattern I see with Bullhorn: consultants are exporting placement data to Excel every month to run commission calculations, because Bullhorn's reporting layer can't handle tiered commission logic or split placements cleanly. That's a genuine reporting gap, and it creates real margin leakage - miscalculations, delays, disputes. But it's not a fundamental platform failure. It's a gap that a custom reporting layer or a well-built integration can close without replacing anything.

With Vincere, I see agencies building parallel candidate tracking in Airtable or Google Sheets because the custom fields aren't flexible enough for their niche - technical skills matrices for engineering placements, for example, or finance sector competency frameworks. Worth flagging: this is often a configuration problem. Vincere's custom objects have more flexibility than most agencies have explored. Before assuming you need to build something, it's worth finding out whether you've actually hit the ceiling or just the default setup.

There are signals that do indicate genuine platform strain. A Bullhorn database approaching 500,000 candidate records will start to show search performance degradation. A 50-consultant team where pipeline visibility is breaking down because the reporting layer can't aggregate cleanly across divisions is a different kind of problem. Volume and headcount create real limits that configuration can't fix.

The diagnostic test I use: if the workaround involves a person manually moving data between two systems more than once a week, that's a process or integration problem. If the system literally cannot store or process the data type you need, that's a platform limitation. One is solvable with middleware. The other might warrant a build.

Build vs. buy vs. extend: an honest framework

Buy: switching platforms

A platform switch is the right call when your current system's data model is fundamentally wrong for your business type. The clearest example: a permanent-only agency that has moved into contractor staffing and is running on a platform with no timesheet or payroll module. You can't integrate your way out of that gap permanently - the core data model doesn't support what you're doing. Similarly, agencies still on genuinely legacy systems like Adapt or Bond that are approaching end-of-life are often better served by migrating than by building custom extensions on top of an uncertain foundation.

The switching cost is real: migration, retraining, the productivity dip while consultants find their feet. But it is often cheaper over a 3-year horizon than building and maintaining custom software to prop up a platform that was never right for the job.

Extend: API integration and middleware

For the majority of agencies asking about custom software development for recruitment agencies, extending the existing stack is the right answer. A custom reporting layer pulling Bullhorn data into Looker Studio or Power BI. A compliance workflow built in n8n that handles GDPR consent tracking without touching the core ATS. A HubSpot integration that syncs candidate and client data for marketing and BD workflows. These are buildable at a fraction of custom development cost, they don't require you to maintain a codebase, and they can usually be delivered in weeks rather than months.

A well-built n8n workflow or Bullhorn API integration costs £5,000-£15,000. A custom build costs £25,000 at minimum. The functional gap that justifies the difference needs to be real and quantified before you commit.

Build: when it's genuinely the right call

A custom build is warranted when the agency has a workflow or data model that no existing platform supports - typically niche-specific use cases, or where the agency is building a candidate-facing product (a portal, an assessment tool, a contractor app) that is a commercial offering in its own right, not just internal tooling. It's also warranted when the agency has already maxed out extending and the integration complexity has itself become the problem - too many moving parts, too many points of failure, too much maintenance overhead spread across disparate middleware.

One thing worth saying plainly: development partners will rarely tell you to extend rather than build, because there's no margin in it for them. A consultancy with no software development revenue has no incentive to push you towards a build. I do n8n automations and integrations, not bespoke development, which is part of why I'm comfortable telling agencies when a build isn't the right answer.

What custom recruitment software actually costs in the UK

MVP build costs

An MVP build - roughly 3-4 months of development, UK agency rates - typically runs £25,000-£60,000 depending on scope. At the lower end, you're looking at a simple candidate portal or a custom reporting tool with one or two platform integrations and a basic admin interface. At the upper end: a timesheet and approval workflow with Bullhorn write-back and a client-facing interface. No native mobile at either end of that range - that adds cost and timeline significantly.

Senior UK developers at a London agency are billing at £600-£900 per day. Nearshore - Poland, Portugal, Romania - comes in at £250-£450 per day. The gap looks compelling in a spreadsheet. But nearshore adds coordination overhead, time zone friction, and communication risk on a domain as specific as UK recruitment compliance. IR35 rules, GDPR obligations, ATS-specific API behaviour - these are not areas where a development team that doesn't know the UK recruitment market will self-correct. Factor that in.

Full platform build costs

A genuine bespoke platform - multi-user, multi-role, custom data model, compliance-ready, with a proper test suite and documentation - runs £80,000-£200,000 and takes 6-12+ months. Most agencies don't need this and shouldn't be buying it. If a development partner is proposing this as a starting point for a relatively contained problem, that's a signal to get a second opinion.

The costs that don't appear on the invoice

The 15-20% annual maintenance overhead is the figure agencies most consistently underestimate. A £60,000 build needs £9,000-£12,000 per year in ongoing maintenance - bug fixes, dependency updates, platform API changes (Bullhorn ships breaking changes periodically, and those changes can break write-back integrations silently), and minor feature additions. Systems that aren't actively maintained degrade. Eighteen months post-launch is when agencies typically notice.

Beyond maintenance, the hidden cost categories that never appear on the project invoice include:

• Internal project management time - a senior ops person spending 20-30% of their time for 6 months is a significant cost that doesn't show up anywhere

• User training and change management - more on this in the post-launch section

• Data migration - particularly if the source data is dirty, which it usually is

• Feature creep - the project spec'd at 3 months routinely runs to 6-9 once stakeholders see the first working version and start adding requirements

Integration complexity with UK recruitment platforms

How the main UK platforms behave in practice

Bullhorn has a well-documented REST API, but the data model is complex. Entities like Candidate, ClientContact, JobOrder, Placement, and Tearsheet have non-obvious relationships that aren't fully explained in the documentation - you learn them by working with the API and hitting failures. Rate limits on standard contracts are typically 200 requests per minute, raiseable with Bullhorn support. Webhook support exists but is unreliable on lower-tier plans. Writing back to Bullhorn - rather than just reading from it - adds significant complexity. Required fields are enforced at the API level, and if you get them wrong, records get rejected silently, which is a debugging problem you want to discover in development, not in production.

Vincere uses a GraphQL API, which is more modern but less widely supported by off-the-shelf tools. Real-time sync is harder to achieve than with REST. Custom reporting that sits on top of Vincere data typically requires pulling to a data warehouse - BigQuery or Postgres - because querying Vincere directly at volume is slow and can hit query limits.

Mercury has an older, less comprehensive API with fewer native integration options. Agencies on Mercury who need to extend are often better served by a database-level integration where Mercury exposes read access to its underlying SQL schema. That requires a Mercury support agreement and introduces upgrade risk - worth having that conversation with Mercury before speccing the project.

JobAdder has a cleaner REST API than Bullhorn with decent webhook support. Lower market share in UK recruitment but used in some exec search firms, and generally a more straightforward integration target.

Where middleware tools can substitute for custom development

n8n or Make can handle a surprising amount of the integration use cases that agencies assume require custom development. A Bullhorn-to-HubSpot sync, a compliance consent workflow, a timesheet notification system - these are all buildable in n8n at a fraction of the cost of a custom build. The limitations are specific: complex conditional logic that requires a proper programming language, any kind of custom UI, or high-volume real-time processing that a polling-based workflow can't support. Outside those constraints, middleware is almost always the faster and cheaper path.

Compliance tools that need to write back consent records to the ATS are harder than they look - most ATS platforms weren't designed to be written to by external systems. And a candidate portal with real-time sync requires an event-driven architecture using webhooks and a message queue, not a polling approach. Getting that right takes time and means the "simple integration" can quietly become a custom build if you're not clear about the architecture from the start.

UK compliance requirements your build needs to handle

If you're building custom software that holds candidate PII, GDPR data retention logic needs to be designed in from the start. ICO guidance for recruitment agencies is that candidate data can be retained for a reasonable period after last contact - typically interpreted as 12-24 months - but your system needs to support automated deletion or anonymisation workflows. Retrofitting that logic into a data model that wasn't designed for it is expensive and error-prone.

Right to erasure creates a specific complication in recruitment: placement records may need to be retained for tax and contractual reasons even when the candidate requests erasure. A custom build needs to handle the distinction between anonymising the candidate record and preserving the commercial record. Most off-the-shelf systems handle this poorly, and custom builds inherit the same problem if it isn't specced before development starts.

If the system is storing candidates for future opportunities - rather than an active application - you need a lawful basis for processing, and consent is the most likely option. That means a consent audit trail baked into the data model: who consented, when, to what, and via which channel. This is not something you can add as a column to a database table after the fact.

For agencies placing contractors: if the custom platform holds engagement records, IR35 status determinations need to be documented and associated with the contractor record. The platform needs to support storing and versioning those determinations - not just a freetext notes field that someone can overwrite.

One that agencies consistently overlook: if you're using offshore development partners with access to production candidate data during development or testing, that's a data transfer under UK GDPR. It needs to be covered by an appropriate mechanism - adequacy decision or Standard Contractual Clauses. Development and test environments should use anonymised data. This is an architectural decision that needs to be specified before the project starts, not a policy question you answer later.

What post-launch actually looks like

The most common post-launch failure mode isn't technical - it's behavioural. Consultants who were using the workaround (the spreadsheet, the manual process) often continue using it alongside the new system rather than instead of it, particularly if the new system has any friction or unfamiliar UI. Six months post-launch the agency has the same manual process plus a new piece of software to maintain. The system didn't fail. Adoption did.

There's also a consistent gap between what was spec'd and what's needed. A requirements document written 6 months ago was based on how stakeholders thought they worked, not how they actually work. The first working version of the software will surface requirements that nobody articulated because they were so embedded in the existing process that nobody thought to mention them. Budget for a change request phase - it typically adds 20-30% to the original project cost, and it's not the development partner's fault.

Codebase ownership is a contractual point that needs to be settled before the project starts. If the development partner holds the code in their own repository and the relationship ends, the agency can be left with a running system they can't modify or maintain. Requirements: IP assignment in writing, repository access from day one, code escrow arrangements if the partner is a small agency, and documentation requirements specified in the contract - not assumed.

Who fields the bug reports post-launch? Who manages server infrastructure? Who updates dependencies when there's a security vulnerability? If the answer is "the development partner on a retainer", make sure that retainer is contracted and priced before go-live, not discussed after the handover call.

Most serious issues surface in the first 6 months - edge cases in the data model, performance problems at volume, integration failures when a connected platform ships an update. Budget and resource for this period explicitly. It's not a sign that the project went wrong. It's just how software behaves in the real world.

When extending your existing stack is the better answer

Before committing to a custom software development project, map the specific workflows that are actually broken. What data needs to move where? How often? Who triggers it? In most cases, that mapping reveals that the problem is solvable with a well-built integration and a cleaner process. The pain is real, but the cause is usually a process that hasn't been mapped properly, a configuration that hasn't been touched since 2019, or an integration gap that middleware can close in weeks.

Problems that n8n automations solve cleanly, and at a fraction of build cost:

• Automated candidate compliance reminders - right to work document expiry, DBS check renewal - triggered from Bullhorn field data

• Timesheet chasing workflows for contractor-heavy agencies

• Candidate reactivation campaigns triggered by database dormancy rules

• Commission calculation exports that pull placement data from Bullhorn and push to a formatted spreadsheet or accounting system

Problems that a HubSpot implementation solves: client relationship management that ATS platforms handle poorly - marketing automation, pipeline visibility for new business development, client contact engagement tracking, BD workflows for account managers who need CRM functionality that Bullhorn wasn't designed to provide.

The cost comparison matters here. A Bullhorn API integration with a custom reporting layer in Looker Studio costs £8,000-£20,000 and can be delivered in 4-6 weeks. A compliance workflow in n8n costs £3,000-£8,000. A full HubSpot implementation with Bullhorn sync costs £10,000-£25,000. Compare those numbers against a £60,000 MVP build before deciding - and make sure you're comparing against a build that actually solves the same problem, not a broader one.

If you're not sure which category your problem falls into, the Revenue Audit at stacklogic.co.uk/services is the logical first step. It maps the actual gaps in your process and stack, identifies what's solvable with configuration or middleware, and gives you an honest picture of whether a build is warranted - before you've committed a development budget to finding out the hard way.