Candidate and client portal
development for recruitment teams

We build candidate and client portals that combine application tracking, document handling, status updates, messaging and role-based access in one place. The portal runs on either WordPress with custom plugins or a custom CMS, syncs with your ATS via API, and gives candidates, clients and recruiters their own dedicated views with the right permissions.

Typical features include candidate registration, CV and document upload, application status timelines, interview scheduling, client shortlists, audit logs and admin controls. We also build the integrations that make the portal talk to your ATS, CRM, calendar tools and notification systems. For most teams this lands as a custom software project with a clear scope rather than a generic off-the-shelf portal.

We’ve integrated portals with Greenhouse, Lever, Teamtailor, Recruitee, Workable, Bullhorn and several niche European systems. If the ATS exposes a REST API or webhooks, we can sync candidate data, application statuses, documents and notes both ways. If the ATS has an older SOAP or file-based interface, we work around it with middleware.

ATS sync isn’t a tick-box feature. Each system has its own rate limits, its own way of mapping custom fields, and its own pain points around webhooks versus polling. We treat the integration design as a separate work block in the scope: which events trigger which sync, what happens when sync fails, how to monitor drift between portal and ATS, how to handle deletions. That’s usually a week or two of dedicated work depending on how clean the ATS API is.

Each role gets a dedicated view with permissions that limit what they can see, do, edit and download. A candidate sees their own application, status and documents. A client sees their assigned shortlists and feedback flows. A recruiter has internal status notes, candidate routing and bulk actions. An admin handles user management, audit logs and integration health.

Permissions get checked at three levels: the route (can the user access this page at all), the data query (can they see this record), and the field (can they see this specific field on the record). That last one matters for things like salary expectations or internal notes that should stay invisible to candidates and clients. We design the role map with you in the discovery phase, then test each role separately before launch. Adding a new role later is a scope-defined task, not a rebuild.

WordPress works when the portal sits next to a content-driven recruitment website, when your team is already comfortable editing in WordPress, and when the integrations needed are relatively standard. A custom CMS or custom application makes sense when permissions get complex, when you need uncommon data models (multi-client workflows, niche compliance flows), or when performance demands are high (many concurrent uploads, real-time status updates).

We’ve done both. A WordPress portal with custom plugins keeps everything in one familiar admin and works well for recruitment agencies and staffing companies under, say, 50 concurrent users at peak. A custom build (Laravel, Node.js or a similar stack) gives more control when the portal becomes the operational system rather than just a candidate-facing extension of the website. The right answer usually comes down to your roadmap: where the product is going in two years, not just at launch. More background in our CMS development work.

Personal data sits in EU-hosted databases by default (Dutch or German datacentres), encrypted at rest and in transit. Role-based access controls limit who can see what, audit logs record every change, and consent records are stored separately so retention rules can run automatically. We sign a Data Processing Agreement (DPA) with you, and any subprocessors are listed in advance.

GDPR around candidate portals usually has two pressure points: retention (how long can you keep CVs and personal data after an application closes) and consent (proving the candidate agreed to processing). We build retention rules into the data model itself, so deletion happens on schedule rather than depending on someone remembering to run a cleanup script. For consent, we keep an immutable log of when, where and how it was given, separate from the application record. If you have industry rules on top of GDPR (financial services background check rules, healthcare-specific requirements), we work around them in the data model rather than bolting them on later.

Our hourly rate is €60-€65 across all roles (UX, frontend, backend, project management, QA), with our team split between Zwolle and Chandigarh. A typical candidate portal project sits in the €10,000 to €35,000 range, depending on which ATS, how many user roles, how complex the document handling is, and whether you need multi-tenant features. Timelines run from roughly 6 weeks for a focused WordPress portal up to several months for a custom multi-tenant build.

The biggest variable in scope is the integration side: a clean Greenhouse or Teamtailor integration is much faster than a custom integration with an older internal system. The second is multi-client logic. A single-tenant portal (one company, many candidates) is simpler than a multi-tenant portal (an agency with multiple client companies, each seeing only their own data). We scope integration and role complexity in the discovery week so you get a defensible number rather than a placeholder. Schedule a discovery call to walk through your specific requirements.

Yes. After launch we offer ongoing support and maintenance through three packages: Care (4 hours per month, 24 working-hour response), Growth (8 hours per month, 8-hour response) and Partnership (16 hours per month, 4-hour response). Pricing starts at €240 per month, with a three-month minimum term, then monthly cancellable with one month notice.

Most portals need continuous attention rather than just bug fixes: ATS API changes (vendors update endpoints regularly), new compliance rules, new client onboarding flows, new feature requests from candidates or recruiters. For teams who ship features regularly, we also run a dedicated-developer model where a fixed-capacity developer (40 to 160 hours per month) works as an extension of your team. That keeps continuity instead of treating every change as a separate project.