Most founders and operations leads who start asking whether to build their own HR system already have a shelf of vendor demos behind them. The question that actually matters is narrower than “build or buy”: does your leave, shift and absence logic fit inside someone else’s rules engine, or does it not? Everything else follows from that answer.
What off-the-shelf platforms are genuinely good at
Standard holiday booking, approval chains, sickness recording, and self-service for staff to check their own balance: this is commodity software now, and buying it is usually the right call. A subscription platform gives you a maintained product, a vendor who patches security issues, and a support line when something breaks. None of that is free to replicate in-house, and for a huge share of small and mid-sized teams the standard model covers the job completely.
The mistake is treating this as a permanent verdict rather than a fit check against your specific rules. Fit changes as a company grows, adds sites, adds shift patterns, or starts operating under more than one set of employment terms.
Where the fit starts to break
Shift patterns the vendor never modelled
Most HR platforms are built around a fairly small set of shift and accrual patterns. Rotating shifts combined with on-call cover, holiday accrual that varies by contract type, or overtime rules that interact with statutory leave, tend to sit outside what the standard configuration screen supports. You can often force a fit with workarounds, spreadsheets on the side, or a support ticket that never quite gets resolved. That workaround cost is real, and it compounds every month the mismatch stays unaddressed.
Approval chains with real-world exceptions
A single line manager approving a holiday request is easy for any vendor to support. Delegated approval while that manager is themselves away, seasonal blackout periods that only apply to certain teams, or sign-off that needs to route differently depending on request length, is where configuration screens run out of options. If your actual process needs a flowchart to explain, a generic SaaS form is rarely going to reproduce it faithfully.
Data that needs to live somewhere else
Absence and scheduling data rarely stays useful in isolation. It needs to reach payroll, sometimes a rota system that also handles site cover or equipment allocation, and occasionally an operational platform that already tracks staff against assets or shifts. Vendor integrations cover the popular payroll providers well. They cover a bespoke internal system, or a less common combination of tools, much less reliably. If the answer to “how does this connect to what we already run” is “export a spreadsheet and re-import it”, that is a sign the platform’s boundary does not match your organisation’s boundary.
Records your sector or regulator asks for
Working Time Regulations record-keeping, sector-specific audit requirements, or reporting formats a particular client or regulator insists on, sometimes fall outside what a general-purpose HR tool exports by default. Custom report building is possible on most platforms, but it has limits, and those limits show up exactly when an audit is due and there is no time left to negotiate with vendor support.
What building actually costs, beyond the first release
The build option is usually assessed against the cost of the first version, which is misleading. The real cost is what comes after: absence rules change when employment law or a union agreement changes, edge cases accumulate as the company grows, and someone has to own security patching for a system that holds sensitive personal data under UK GDPR. A platform vendor spreads that maintenance cost across every customer they have. A bespoke internal system spreads it across one company, which means it never gets cheaper per user the way a SaaS subscription does.
None of this rules building out. It means the honest comparison is subscription cost against total cost of ownership over several years, not subscription cost against one development invoice.
The middle path most teams skip past
The binary framing of build versus buy misses a third option that fits a lot of the cases above: buy the commodity core and build only the piece that is genuinely specific to how the business runs. Standard leave booking, approvals and self-service stay on a maintained platform. The scheduling engine that has to reconcile rotating shifts with equipment cover, or the integration that pushes absence data into an existing operational system, gets built as a smaller, targeted piece of software that talks to the platform rather than replacing it.
This is the shape of the problem we built Calendar RRHH to solve for our own use first: standard HR mechanics handled in a straightforward way, with the shift and absence logic that a generic tool would not model built in directly rather than bolted on as a workaround. That experience is why we tend to push back on a full custom build request until the specific mismatch has actually been named. Most of the time, only one part of the system needs to be bespoke, not all of it.
A decision checklist
- Can you describe your absence and shift rules in under a page? If not, a generic configuration screen is unlikely to hold them either.
- Have you already built workarounds (spreadsheets, manual exports, side processes) to cover a gap in your current platform? List them; each one is a specific requirement, not a general complaint.
- Does your data need to reach a system your HR vendor does not integrate with well, and does that gap recur every month?
- Would a bespoke scheduling or reporting component, sitting alongside a standard HR platform, close the gap without replacing the whole system?
- Have you costed maintenance, security patching and future rule changes over three to five years, not just the first release?
- Is the exception you are solving for actually rare, or does it affect most of your staff, most of the time? Rare exceptions are usually cheaper to manage manually than to automate.
If most of these point towards a narrow, well-defined gap rather than a wholesale mismatch, that gap is usually what is worth commissioning, not a replacement for the whole HR platform.