HRMS: build or buy
The tell is the shadow spreadsheet. If your real leave rules live outside the HRMS, the product does not fit your policy.
Custom build
Your policy, expressed exactly
HR product
Statutory updates maintained for you
There is a specific signal worth looking for before anything else. Somewhere there is a spreadsheet that is the actual source of truth for leave balances, and the HRMS holds a version nobody trusts. That spreadsheet exists because the product's accrual rules do not match the handbook, so the policy moved somewhere the software could not constrain it.
If that spreadsheet does not exist in your organisation, buy a product. If it does, the question becomes whether the mismatch is worth building around — and sometimes the right answer is still to change the policy rather than the software.
Where they actually differ.
| Dimension | Custom build | HR product |
|---|---|---|
| Policy fit | Accrual, probation, shift and approval rules expressed exactly as written. | Good for conventional policies. Unusual rules become a spreadsheet beside the system. |
| Statutory compliance | You track legislation. This is the single strongest argument against building. | The vendor maintains registers, returns and rate changes. Genuinely valuable. |
| Payroll calculation | Almost never worth building. Rates and rules change several times a year. | Solved, and correctly. Integrate with it rather than replacing it. |
| Multi-jurisdiction | Conflicting rules per location modelled properly rather than approximated. | Varies sharply by vendor; many handle one country well and others poorly. |
| Sensitive data control | Field-level access, read auditing and residency designed to your requirement. | Usually role-based at screen level. Adequate for many, insufficient for some. |
| Employee experience | Built for your workforce — including people on shared devices with poor signal. | Generally polished, occasionally assumes a desk worker with a laptop. |
| Cost | One-time build plus maintenance; no per-employee fee as you grow. | Per-employee monthly, which compounds quietly with headcount. |
| Time to live | 12–20 weeks depending on module scope. | Weeks, mostly spent on data migration and policy configuration. |
- Your leave, shift or attendance rules are genuinely unusual and the shadow spreadsheet already exists.
- You operate across jurisdictions with conflicting requirements that no single product handles well.
- You need field-level control over salary, performance and medical data beyond what products offer.
- Headcount is large enough that per-employee pricing is material.
- HR needs to share a data model with an existing custom ERP or operations platform.
- Your policies are conventional, or could reasonably be simplified to match a good default.
- You want statutory registers, returns and rate changes maintained for you — this is the strongest single reason to buy.
- You are under a few hundred employees in one jurisdiction.
- You need payroll calculation itself. Buy this. Building it is a permanent legislative treadmill.
- You have no engineering capacity to maintain what gets built.
Our view
The split that works for most: buy payroll calculation and statutory filing, build the workflow layer if — and only if — your policy genuinely cannot be expressed in a product. And check first whether the policy is worth keeping. We have seen a custom build commissioned to preserve an accrual rule nobody could justify when asked directly.
Follow-ups.
Would you build payroll calculation?
No, and we will push back if asked. Statutory rates and rules change several times a year in most jurisdictions, and a bug there is a legal exposure rather than an inconvenience. We compute and reconcile the inputs and integrate with a licensed processor.
What about keeping the product and building only what is missing?
Often the right answer, and cheaper than either extreme. Keep the HR product as the employee record and payroll integration, and build the shift planning or approval workflow it cannot express, with a properly reconciled integration.
How do you handle sensitive employee data differently?
Authorisation on the field rather than the screen, so a manager sees leave without seeing salary. Reads of sensitive records are logged, not only writes. Retention is purpose-limited and enforced as scheduled deletion.
Tell us what you are building.
A short conversation is usually enough to tell whether we are the right firm for the problem. If we are not, we will say so and point you somewhere better.