Recruitment Platforms: Connecting Employers and Candidates

Modern recruitment platforms have moved well past job boards. They are now complex, data-heavy systems that touch applicant tracking, skills assessment, calendar scheduling, background verification, and offer management, all within a single product. Building one means making real architectural decisions, not just wiring together a few forms and a database.

This post covers how these platforms are structured, where the hard problems actually live, and what trade-offs you are likely to face if you are building or significantly extending one.

What Does a Recruitment Platform Actually Need to Do?

The functional scope is broader than most people assume at the outset. At minimum, a platform needs to handle:

• Job requisition creation and approval workflows
• Candidate sourcing (inbound applications, outbound sourcing, referrals)
• Resume parsing and structured profile creation
• Interview scheduling coordinated across multiple calendars
• Assessment delivery and scoring
• Communication threading between recruiter, hiring manager, and candidate
• Offer generation and e-signature
• Reporting and pipeline analytics

That list is not exhaustive. Compliance requirements (GDPR, EEO, OFCCP in the US) add data retention rules, consent flows, and audit logging on top of every one of those features.

The Employer Side vs. the Candidate Side

These two surfaces have very different requirements. The employer side is a B2B workflow tool. It needs role-based access control, approval chains, bulk actions, and deep integration with HRIS systems like Workday or SAP SuccessFactors. The candidate side is a consumer-facing product. It needs fast load times, mobile-first design, clear progress indicators, and low friction at every step because drop-off rates between job application start and submission routinely exceed 60%.

Building both well inside one product is genuinely difficult.

How Should the Data Model Be Structured?

This is where most platforms get into trouble, because the relationships are non-trivial.

A Job is posted by an Organisation and has one or more Requisitions. Each Requisition produces a Pipeline with configurable stages. A Candidate can apply to multiple jobs at the same organisation, and their application data should be scoped per application, not globally, because the same person may be a strong fit for one role and a weak fit for another.

Interview feedback, assessment scores, and recruiter notes all need to hang off the Application object, not the Candidate object. This is a data modelling mistake that is easy to make early and painful to undo at scale.

A few specifics worth thinking through:

Entity	Common mistake	Correct approach
Candidate profile	One global profile with all notes	Application-scoped data; shared identity layer
Interview slots	Storing as flat timestamps	Calendar event objects with attendee state machines
Assessment scores	Raw scores only	Normalised percentile + raw, with version reference
Job stages	Hardcoded pipeline steps	Configurable stage templates per org or job type

Postgres works fine as the primary store for most of this. You will want a separate search layer, typically Elasticsearch, for full-text candidate search across large corpora. Redis is useful for session state and short-lived scheduling locks.

What Are the Real Engineering Challenges?

Resume parsing is harder than it looks. State-of-the-art models like those built on BERT fine-tuned on resume corpora still produce structured output that needs validation. Fields like "years of experience" are inferred, not extracted, and inference errors compound downstream in ranking and filtering. If you are building your own parser, budget time for a human-in-the-loop correction workflow. If you are integrating a third-party service like Affinda or Sovren, test their output against your actual candidate pool before committing.

Calendar coordination is a persistent source of bugs. The problem is that availability changes between when a candidate selects a slot and when a recruiter confirms it. You need an optimistic lock on slot selection, a short expiry window (typically 15 minutes), and a fallback flow for when the lock expires. Most teams underestimate this until they have production complaints.

Matching and ranking is where teams most often reach for machine learning too early. A well-tuned keyword and rule-based filter with explicit weighting on fields like location, seniority, required skills, and visa status will outperform a poorly trained ML model with insufficient labelled data. If you have fewer than 50,000 labelled application outcomes, start with deterministic scoring. Add a learned component once you have the data volume and a feedback loop from hiring outcomes.

Integrations You Cannot Avoid

Any platform serving mid-market or enterprise employers will eventually need:

• HRIS sync: Bidirectional with Workday, BambooHR, or SuccessFactors. Expect their APIs to be inconsistent and their sandbox environments to behave differently from production.
• Calendar APIs: Google Calendar and Microsoft Graph both require OAuth 2.0 with refresh token handling. Webhook reliability on Microsoft Graph in particular needs a fallback polling mechanism.
• Background verification: Checkr and Sterling both have REST APIs. Turnaround SLAs vary by check type and geography. Model this as an async process with status webhooks, not a synchronous call.
• Video interviewing: Native build vs. embedding a provider like Zoom SDK or HireVue. Embedding is faster to ship but gives you less control over data residency and recording storage.

How Do You Handle Multi-Tenancy Correctly?

Most recruitment platforms are multi-tenant SaaS products. The two common patterns are schema-per-tenant and shared schema with a tenant ID column. Schema-per-tenant gives you hard isolation and simpler data deletion (GDPR right to erasure becomes a schema drop), but makes cross-tenant analytics and migrations more expensive. Shared schema is operationally simpler but requires disciplined query hygiene and row-level security policies, which Postgres supports natively via CREATE POLICY.

For most teams building at early scale, shared schema with RLS is the right starting point. Schema-per-tenant becomes worth the operational overhead when you have enterprise clients with contractual data isolation requirements or when your migration complexity is already hurting you.

Conclusion

Recruitment platforms are not technically exotic, but they have enough moving parts, data model subtleties, and integration surface area to go wrong in ways that are expensive to fix later. The decisions that matter most: get the application-scoped data model right from the start, do not reach for ML ranking until you have labelled data, and treat calendar coordination as a distributed systems problem, not a UI problem.

If you are scoping a build or trying to untangle an existing architecture, we are happy to talk through the specifics. You can reach the Sodio engineering team through the contact page.

FAQ

What is the difference between an ATS and a full recruitment platform? An applicant tracking system (ATS) handles applications and pipeline stages. A full recruitment platform adds sourcing, assessment, scheduling, offer management, and analytics. The distinction matters for build-vs-buy decisions. An ATS can be integrated; a platform is usually the system of record.

Should we build resume parsing in-house or use a third-party service? Use a third-party service unless you have a very specific parsing requirement that off-the-shelf tools cannot meet. Providers like Affinda and Sovren have years of training data. Building from scratch is a significant ML investment with long payback periods. Integrate first, build only if the output quality demonstrably fails your use case.

How do we handle GDPR compliance in a recruitment platform? Map every data collection point to a lawful basis, typically legitimate interest for employer-initiated sourcing or consent for candidate-submitted applications. Implement configurable retention periods per data category. Support right-to-erasure requests with a documented deletion workflow. Audit logs for data access should be append-only and stored separately from operational data.

When does it make sense to add ML-based candidate ranking? When you have at least tens of thousands of labelled application outcomes tied to actual hiring decisions. Without sufficient labelled data, a tuned rule-based scoring model will outperform a learned one. ML adds value when you have the data volume, a feedback loop from hiring outcomes, and the tooling to monitor for bias drift over time.

What database should a recruitment platform be built on? Postgres handles the relational core well: applications, jobs, candidates, interviews. Add Elasticsearch for full-text and faceted candidate search. Redis for locks, session state, and rate limiting. Avoid NoSQL for the core data model; the relational structure of recruitment data maps naturally to tables, and you will want joins for reporting.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.