Industry
Software engineering for Human Capital Management
Human capital management looks like forms and workflows until payroll runs. Then it is unforgiving: PAYE, National Insurance and pensions have to be exactly right, RTI has to reach HMRC on time, auto-enrolment has to be handled correctly, and the data underneath is some of the most sensitive an organisation holds. The hard part is not the org chart: it is payroll correctness, special-category employee data, and the integration sprawl that connects HR to finance, ERP and every downstream system. We build for that reality, not the demo.
Why the domain matters
Human capital management is deceptively broad (it spans hiring, onboarding, the core employee record, performance, absence, and payroll), and most of it looks like ordinary forms-and-workflow software right up until money and sensitive data enter the picture. Then the character of the work changes completely. Payroll has to be exactly right, because an employee who is underpaid or overpaid, or whose tax and National Insurance are wrong, has a real and immediate problem, and the employer has a statutory and reputational one. The employee record holds some of the most sensitive personal data an organisation keeps. And nothing in HCM stands alone: it feeds finance, it draws from time and attendance, it connects to pensions and to HMRC. Success here is defined by correctness and by careful handling of sensitive data, not by the breadth of the feature list.
The hard centre of HCM is payroll, and payroll is unforgiving in a way most software is not. In the UK it means operating PAYE correctly, calculating National Insurance and statutory payments, applying tax codes, handling pensions auto-enrolment and contributions, and reporting to HMRC in real time through RTI on or before each payday. There is no partial credit: a payroll that is nearly right is wrong, and the errors surface immediately in people’s bank accounts and in HMRC submissions. Around payroll sits the rest of HCM: the HRIS as the record of who works here, applicant tracking and onboarding that feed it, and performance and absence that hang off it, but the discipline that payroll demands sets the tone for the whole system, because so much of it ultimately flows into a number that has to be paid correctly and reported on time.
We are a senior-led team and we operate what we build, so we start from where the real risk lives (payroll correctness, sensitive-data handling and integration), rather than from the parts that demo well. The failure mode in HCM is software that treats payroll as just another workflow, that scatters special-category employee data without care, or that underestimates how many systems it has to talk to and ends up an island that finance cannot reconcile. We would rather build the unglamorous correctness, the disciplined data handling and the reliable integrations than the polished self-service screen that hides a payroll engine nobody can trust. This is about the machinery that pays people accurately, protects their data, and connects cleanly to the rest of the business.
The challenges in human capital management
Payroll has to be exactly right, with no partial credit
Payroll is the least forgiving part of HCM. PAYE, National Insurance, tax codes, statutory payments and pension contributions all have to be calculated correctly, every period, for every employee, and an error is not a cosmetic defect, it is someone underpaid or overpaid and a tax submission that is wrong. There is no “nearly right” in payroll; the mistakes surface immediately in bank accounts and in HMRC filings. Building here means engineering for correctness with the seriousness that money and statutory reporting demand.
HMRC RTI and statutory reporting on a fixed clock
Real Time Information requires PAYE data to be reported to HMRC on or before each payday, with further year-end obligations, and auto-enrolment brings its own duties around assessing and enrolling eligible workers and handling contributions. These are time-bound statutory obligations, not internal niceties: the reporting has to be accurate and on time. Software that touches payroll has to respect these rhythms and specifications exactly, because a late or incorrect RTI submission is a real problem for the employer, not a backlog item.
Special-category and sensitive employee data everywhere
The employee record holds far more than names and salaries. It can include health and sickness data, information relating to protected characteristics, financial details, and other special-category data under UK GDPR that demands stricter handling. This data is spread across HR, payroll, absence and performance, and it is exactly the kind that turns a loose access model into a serious incident. Handling it carelessly is one of the fastest ways HCM software becomes a liability rather than an asset.
Integration sprawl that turns HCM into an island or a mess
HCM does not stand alone. It feeds the general ledger in finance and ERP, draws from time-and-attendance and rota systems, connects to pension providers and to HMRC, and often has to reconcile with an ATS, a benefits platform and more. That is a lot of integration surface, and getting it wrong leaves an HCM system that finance cannot reconcile or that duplicates data inconsistently. The integration is not a side task; it is a defining part of whether the whole thing works.
Correctness that depends on messy upstream data
A payroll run is only as correct as the data feeding it, starters and leavers, hours and overtime, absence and statutory leave, changes to pay and tax codes. Much of that arrives late, in inconsistent formats, or from other systems and managers who did not treat it as time-critical. A large part of building reliable HCM is validating and reconciling that upstream data before it reaches the payroll engine, because an error that flows in unnoticed becomes an error someone is paid.
A system employees judge personally and immediately
HCM is unusual in that every employee is a user with a personal stake. Their pay, their leave, their data. When a payslip is wrong, a holiday balance is off, or a self-service portal is confusing, people notice at once and trust erodes quickly, because this is about their money and their working life. That raises the bar on both correctness and usability, and it means the failure modes are visible across the whole organisation, not hidden in a back office.
What we build for human capital management
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
HRIS and core employee record
A reliable system of record for who works in the organisation (employees, contracts, roles, pay and the changes over time), built to be the trustworthy single source that the rest of HCM depends on. We treat the core record as foundational, because payroll, reporting and every downstream integration are only as correct as the employee data underneath them, and a record that quietly diverges is where a surprising number of payroll and compliance errors actually begin.
Payroll with RTI, PAYE and auto-enrolment
Payroll engineered for the correctness it demands. PAYE, National Insurance, tax codes, statutory payments and pension contributions calculated right every period, RTI reported to HMRC on the required clock, and auto-enrolment duties handled properly. We build this with the seriousness money and statutory reporting deserve, with validation and reconciliation around the run, because in payroll there is no partial credit and the errors land immediately in people’s pay and in HMRC filings.
Applicant tracking and onboarding
ATS and onboarding that carry a candidate cleanly from application through offer into the employee record, capturing the right data once and feeding it into the HRIS so a new starter exists correctly and on time. Built to handle the sensitive data candidates provide with appropriate care, and to make onboarding smooth for the new joiner, because a stumble at the start of the employment relationship is felt personally and sets the tone for everything after.
Performance, absence and time
Performance, absence and time-and-attendance handled as the operational data that both supports management and feeds payroll, absence and statutory leave that affect pay captured accurately, hours and overtime reconciled, performance recorded fairly. We build these with an eye on the fact that much of this data ultimately flows into a payroll number, so accuracy upstream is not just administrative tidiness, it is payroll correctness by another route.
Finance and ERP integration
The integrations that connect HCM to the rest of the business, posting payroll to the general ledger in finance or ERP, reconciling costs, and exchanging data with pension providers, benefits platforms and HMRC. We treat this integration as core engineering rather than a side task, building it so finance can reconcile cleanly and data is not duplicated inconsistently, because an HCM system that finance cannot trust the numbers from has failed at one of its main jobs.
Employee and manager self-service
Self-service that genuinely reduces HR load, employees viewing payslips, booking leave and updating details, managers approving and seeing their teams, built on a correct record so what people see is right, and designed with care because every employee judges this personally and immediately. Done well it takes real work off HR and builds trust; done carelessly, a wrong balance or a confusing payslip erodes confidence across the whole organisation at once.
Where we help
A payroll platform that gets RTI right, every period
An organisation needs payroll it can trust. PAYE, National Insurance, tax codes, statutory payments and pension contributions correct every run, and RTI filed to HMRC on the required clock. The real work is correctness and the validation around it: reconciling the upstream data before the run, catching anomalies before they become someone’s wrong payslip, and making the HMRC submission accurate and on time. The measurable win is a payroll that is right and reported correctly, because in payroll nearly right is simply wrong.
An HRIS that finance and ERP can actually reconcile
A growing organisation wants its core people data and payroll to connect cleanly to finance rather than living in an island that produces numbers finance cannot tie out. We build the HRIS as a trustworthy record and engineer the integration to post payroll to the general ledger and reconcile costs consistently. Done well, finance trusts the figures and month-end is smoother; done as an afterthought, the integration sprawl leaves the two sides quietly disagreeing and someone reconciling by hand.
Onboarding that carries a candidate cleanly into payroll
An employer wants a new hire to go from offer to first correct payslip without data being re-keyed or lost between the ATS, the HRIS and payroll. We build the flow so candidate and new-starter data is captured once, handled with the care its sensitivity deserves, and feeds the record and payroll so the person exists correctly and is paid right on their first run. A stumble here is felt personally by the new joiner, so we build it to be smooth and correct rather than a series of disconnected forms.
Self-service that reduces HR load without eroding trust
An HR team buried in leave requests, payslip queries and detail changes wants employees and managers to self-serve. Built on a correct record so balances and payslips are right, and designed with real care because people judge this personally, the portal takes genuine load off HR. Done honestly it cuts queries and builds confidence; built on shaky data, a single wrong holiday balance or confusing payslip undoes that trust across the organisation faster than any feature can rebuild it.
How we build for human capital management
We start from where the real risk lives (payroll correctness, sensitive-data handling and integration), not from the screens that demo well. Before designing anything we want to understand how pay is actually calculated, where the special-category data sits, and which systems HCM has to reconcile with in finance, ERP, pensions and HMRC. In HCM the constraint is correctness and integration, so we design for the payroll that must be exactly right and the data that must not leak, not for the self-service portal that impresses in a walkthrough while the engine behind it is untrustworthy.
We treat payroll with the discipline money and statutory reporting demand. Payroll has no partial credit, so we build validation and reconciliation around the run, engineer for the RTI clock and the auto-enrolment duties, and make anomalies visible before they become someone’s wrong payslip or an incorrect HMRC filing. We would rather invest heavily in getting the unglamorous calculations and submissions right than in surface polish, because in this domain the calculation is the product and everything else hangs off it being correct.
We are blunt about the integration sprawl and resource it as core work. HCM feeds finance and ERP, draws from time and attendance, and connects to pensions, benefits and HMRC, and that surface is where the system either becomes trustworthy or becomes an island finance cannot reconcile. We plan for the messy upstream data, the reconciliation edge cases and the downstream posting from day one, rather than discovering late that the numbers do not tie out and someone is reconciling payroll to the ledger by hand.
Because we operate what we build, the people designing a payroll calculation or an RTI submission are the ones called when a filing is rejected or a payslip is wrong. That concentrates the mind on the failure modes that actually matter in HCM. The pay that must be exact, the special-category record that must not leak, the ledger posting that must reconcile, and keeps us honest about trade-offs up front rather than discovering them in production on a payday, which is the worst possible time to find them.
Regulation and compliance
Payroll sits inside hard statutory obligations that reach directly into the code. Operating PAYE means calculating and deducting income tax and National Insurance correctly, applying tax codes and statutory payments, and reporting to HMRC in real time through RTI on or before each payday, with year-end obligations on top. There is no room for approximation (the figures have to be right and the submissions on time), so we build to these specifications exactly and treat correctness and timeliness as the core requirement rather than a compliance layer bolted on the side.
Pensions auto-enrolment adds its own duties: assessing workers for eligibility, enrolling those who qualify, handling contributions correctly, and managing opt-outs and re-enrolment on the required cycle. These duties are ongoing and specific, and getting the assessment or the contributions wrong has real consequences for employees and the employer. Where our software handles auto-enrolment, it has to implement these rules faithfully and keep the evidence, because the obligation lives in doing it correctly and being able to show it.
Data protection under UK GDPR runs through the whole of HCM, and employee data raises the stakes because it routinely includes special-category data: health and sickness information, data relating to protected characteristics, and sensitive financial details. That demands stricter handling: a clear lawful basis, minimisation, purpose limitation, retention limits and tightly scoped access. We engineer for these from the start, because special-category employee data handled loosely is one of the most common routes from ordinary HR software to a reportable breach.
We build systems that meet these obligations, but we are engineers, not your legal, payroll, pensions or data-protection advisers. The duties around PAYE and RTI, auto-enrolment and UK GDPR carry real legal and financial weight, and sign-off rests with your own payroll, pensions, finance and compliance functions. Our job is to build software that calculates, reports and handles data correctly and keeps the evidence those obligations require, and to work alongside the people who are accountable for them rather than in place of them.
Integration
HMRC is the first non-negotiable integration in UK HCM. Payroll has to submit RTI to HMRC on or before each payday and meet year-end obligations, which means building to HMRC’s specifications and being resilient to their processing: a submission that is late or rejected is a real problem, not a retry-tomorrow inconvenience. We treat the HMRC connection as core engineering that has to be reliable on a fixed clock, because the whole payroll process is judged on the pay landing right and the filing going through.
Finance and ERP are the other end of the payroll flow. Payroll costs have to post to the general ledger and reconcile cleanly, so HCM has to integrate with the finance or ERP system rather than producing numbers finance then wrestles into place by hand. We build this posting and reconciliation deliberately, because an HCM system whose figures finance cannot tie out has failed at one of its central jobs, however good the HR-facing side looks.
Pension providers, benefits platforms, and time-and-attendance or rota systems form the surrounding web. Contributions flow to pension providers, benefits data has to stay consistent, and hours, overtime and absence flow in from time systems and directly affect pay. Each of these is a place where inconsistent or late data becomes a payroll error, so we integrate them with validation and reconciliation rather than trusting that upstream data arrives clean and on time.
The recurring engineering task across all of it is keeping employee, pay and cost data consistent as it crosses the HRIS, payroll, an ATS, finance, pensions, benefits and HMRC: systems that were never designed to agree. We treat that reconciliation, and a single trustworthy picture of each employee and each pay run, as core work, because the correctness that HCM lives or dies on depends entirely on the data staying consistent across a genuinely sprawling integration surface.
Security and data protection
HCM software holds some of the most sensitive data an organisation keeps, employee identities, salaries and bank details, health and sickness records, information relating to protected characteristics, and other special-category data under UK GDPR. That is a serious liability, so we build with access controls scoped tightly to genuine role and need, encryption in transit and at rest, and retention limited to what a lawful basis actually supports. Special-category employee data in particular is not something to spread casually across the system, and we design deliberately to keep it contained.
Access model is where HCM security is won or lost, because the natural pull is to let too many people see too much. A manager does not need every field on their reports, HR does not all need the most sensitive records, and payroll access is its own tightly scoped concern. We design access around real roles from the start (narrow, purpose-limited, and auditable), because an over-broad permission on employee health or financial data is exactly the kind of quiet flaw that becomes a reportable incident.
Payroll and bank details make HCM a direct financial-fraud surface. Changes to bank details, payment instructions and payroll runs are all paths that fraud targets, so we build them with strong authentication, careful handling and controls that make suspicious changes visible rather than silent, because a fraudulent change to where wages are paid does immediate, real harm to employees and the organisation, and it is precisely the sort of thing that must not slip through unremarked.
Because we operate what we build, security here is not a report handed over at the end. We instrument for the access and change patterns that indicate a problem, keep the audit trail a data-subject request or a fraud investigation would need, and treat the ability to reconstruct exactly what happened to an employee’s sensitive data or a payment instruction as part of the deliverable, not something found missing after an incident that involves people’s pay and their most personal information.
What changes
Payroll that is exactly right and reported on time
Because we engineer payroll for the correctness it demands. PAYE, National Insurance, statutory payments and pensions calculated right, with validation around the run and RTI filed on the HMRC clock, pay lands correctly and submissions go through, so the least forgiving part of HCM stops being a monthly source of anxiety.
Numbers finance and ERP can actually reconcile
By treating the integration to finance and ERP as core engineering rather than a side task, payroll posts to the ledger and reconciles cleanly, so the organisation avoids the classic HCM failure of a people system whose figures finance cannot tie out and ends up reconciling by hand.
Sensitive employee data handled with real discipline
Because access is scoped tightly to genuine role and need and the audit trail is treated as part of the deliverable, special-category employee data is kept contained and defensible, which in HCM is the difference between an asset and a reportable breach waiting to happen.
What we build for human capital management
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for human capital management?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in human capital management choose us
We build for payroll correctness, where there is no partial credit
The hard part of HCM is not the org chart, it is a payroll that has to be exactly right and reported to HMRC on time, every period. We engineer for that correctness with the seriousness money and statutory reporting demand (validation, reconciliation and the RTI clock built in), because a payroll that is nearly right is wrong, and the errors land immediately in people’s pay.
We treat special-category data as the liability it is
Employee records hold health, financial and protected-characteristic data that UK GDPR treats as special-category, and it is exactly what a loose access model turns into an incident. We design tight, role-based, auditable access from the start and keep sensitive data contained, because handling it carelessly is one of the fastest ways ordinary HR software becomes a serious breach.
We resource the integration sprawl as core work
HCM feeds finance and ERP, draws from time and attendance, and connects to pensions and HMRC, and that surface is where the system becomes trustworthy or becomes an island. We plan for the messy upstream data and the downstream reconciliation from day one, rather than discovering late that the numbers do not tie out and finance is reconciling payroll by hand.
We operate what we build
The people who design a payroll calculation or an RTI submission are the ones paged when a filing is rejected or a payslip is wrong on a payday. That keeps us focused on the failure modes that matter in HCM. The pay that must be exact, the sensitive record that must not leak, the ledger posting that must reconcile, and honest about trade-offs up front, not discovering them in production at the worst possible moment.
Common questions
What is genuinely the hard part of HCM software?
Not the parts that demo well. The org chart, the workflows, the self-service screens. The hard part is payroll correctness, sensitive-data handling and integration. Payroll has to be exactly right every period, with PAYE, National Insurance, statutory payments and pensions calculated correctly and RTI filed to HMRC on time, and there is no partial credit: nearly right is wrong. The employee record holds special-category data that must not leak. And HCM has to reconcile with finance, ERP, pensions and HMRC across a sprawling integration surface. We build for those three realities specifically, because that is where HCM projects actually succeed or fail.
Can you handle UK payroll. RTI, PAYE and auto-enrolment?
Yes, and we treat it with the discipline it demands rather than as another workflow. Operating PAYE correctly, calculating National Insurance and statutory payments, applying tax codes, reporting to HMRC in real time through RTI on or before each payday, and handling pensions auto-enrolment properly are all things that have to be exactly right and on time. We build validation and reconciliation around the payroll run so anomalies are caught before they become someone’s wrong payslip or a rejected filing. To be clear on the boundary: we are engineers, not your payroll, pensions or tax advisers, and sign-off on your statutory obligations rests with your own payroll and compliance functions.
How do you protect sensitive employee data?
By treating it as the liability it is. Employee records routinely include special-category data under UK GDPR: health and sickness information, data relating to protected characteristics, and sensitive financial details. That demands stricter handling. We design access tightly around genuine roles from the start, narrow and purpose-limited and auditable, rather than letting too many people see too much, which is the natural pull in HR systems and exactly how they become incidents. We add encryption, minimisation and retention limits, and we keep the audit trail a data-subject request or an investigation would need. Accountability for data protection rests with your own functions; we build to support it.
Will this integrate with our finance or ERP system?
Yes, and we treat that integration as core engineering rather than a side task, because it is where HCM either becomes trustworthy or becomes an island. Payroll costs have to post to your general ledger and reconcile cleanly, and HCM also has to connect to pension providers, benefits platforms, time-and-attendance systems and HMRC. We plan for the messy upstream data and the downstream reconciliation from day one, so finance can tie the numbers out rather than reconciling payroll to the ledger by hand. An HCM system whose figures finance cannot trust has failed at one of its central jobs, however polished the HR-facing side is.
Should we build custom HCM or buy an off-the-shelf platform?
Often you should buy the commodity payroll and HRIS and build only where you have a genuine differentiator or a real integration gap, and we will tell you that honestly rather than sell you a rebuild of something the market already does well and cheaply. Payroll in particular is unforgiving and heavily commoditised, so custom-building a payroll engine is rarely wise unless you have a very specific reason. Where custom software earns its place is in the integration layer that ties HCM to your finance, ERP and operational systems, in workflows unique to how you actually run, and in filling gaps the off-the-shelf tools leave. We would rather build that than duplicate a solved problem.
Building for human capital management?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if human capital management is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.