HR Software: How to Choose the Right Stack for Your Size

What counts as HR software?

The label covers four different things, and conflating them is how budgets get wasted. First, the record layer: an HRIS that holds who works here, in what role, since when. Second, the operational tools that run monthly cycles, meaning attendance, leave and payroll. Third, talent tools supporting hiring, onboarding, reviews and development. Fourth, everything adjacent: expenses, assets, helpdesk, engagement surveys. A suite sells you several layers under one login. A point tool does one layer well and expects you to connect the rest. Neither is right in general. The answer depends on how many cycles you run each month and how much administration your team can absorb. Start by writing down which of those four layers currently lives in a spreadsheet, and how long each one takes somebody every month. That list, not a feature comparison, is your requirement document.

Should you build, buy a suite, or stitch point tools together?

Building is almost never the answer for people data. The rules change without warning, the edge cases never end, and the person who wrote your internal tool eventually leaves. That leaves two real options. A suite gives you one employee record, one login and one vendor to chase, at the cost of some depth in any single area. Point tools give you a better fit per problem and hand you the integration bill, because two systems that disagree about a leave balance are worse than one system that is merely adequate at leave. As a rule, buy a suite for anything sharing the employee master - records, attendance, leave, payroll - and buy a specialist where the workflow is genuinely different, which for most companies means hiring. That is exactly why an ATS sits happily beside a core suite. Decide that boundary first, then shortlist.

Which tools does a company actually need at each headcount?

Under about twenty-five people, a spreadsheet and a payroll consultant genuinely work, and buying early mostly buys administration. The first thing to break is usually payroll accuracy, then leave balances, then the question nobody can answer: who reports to whom, and since when. Between twenty-five and a hundred, one suite covering records, attendance, leave and payroll pays for itself in the reconciliation time your finance lead stops losing. Past a hundred, pressure shifts to reporting, approvals and access control, and hiring volume usually justifies a dedicated hiring system. Growth shape matters more than the number, though. A company opening three branches at thirty people needs structure sooner than a single-office company at eighty. Buy for the shape you will be in a year, and leave everything else switched off until you need it. Buying ahead of the shape rarely saves money; it just moves the cost.

How do you write requirements before you take a demo?

Write scenarios, not features. A feature list produces a demo where every vendor says yes. Scenarios expose the differences. Describe your five most awkward monthly events in plain language: the employee who joined on the nineteenth, the shift crossing midnight, the contractor paid differently, the branch whose attendance always arrives late, the resignation with recovery. Add the three reports your management genuinely asks for. Then state constraints honestly - the budget band, who will administer this, and whether anyone can be spared for a migration this quarter. Send that document to every shortlisted vendor before the first call. Two things follow. Demos become comparable, because everyone is solving identical problems. And you learn early which vendors read it, which predicts the implementation better than anything printed on a feature page. Vendors who ignore the document will ignore your edge cases during implementation too.

What should you ask a vendor that they are not expecting?

Ask how a policy change mid-year is handled: recalculated retrospectively, or applied forward only. Ask who configures a new leave type, you or their team, and what that costs after the first year. Ask what happens to your data if you leave, in which formats, from which tables, and how quickly. Ask to speak to whoever would run your implementation rather than the account manager. Ask how support tickets get prioritised, and what the escalation path looks like when payroll is stuck on a Friday evening. Ask what the product does badly, because a vendor with no honest answer is either very new or evasive. Finally, ask for a sandbox holding your own data before you sign. Every one of those questions is about the two years after purchase, where the real cost sits and where demos never go. Write the answers down before the next call.

What makes a purchase go wrong?

Three patterns repeat. Buying on feature count, where the longest list wins the comparison sheet and then nobody configures nine-tenths of it. Buying without an owner, where a founder signs, hands it to an HR executive who was never in the room, and the project stalls at data import. Buying to fix a process problem, because if approvals are slow due to two directors not replying, no workflow engine repairs that; it only sends more reminders. A quieter fourth: signing an annual contract sized for the headcount you plan to reach rather than the one you have. Guard against all four by naming the owner before the shortlist, capping initial scope at two modules, and agreeing a written success test for the first ninety days. A purchase that cannot pass that test was a decision problem, not a product problem.

How do you switch without losing a payroll cycle?

Run parallel. Keep the old process alive for a full cycle while the new system produces the same outputs, then compare line by line and investigate every difference before cutover. Freeze master data during migration, because a system moved while people are joining creates records that exist in one place only. Pick a cutover date at the start of a financial period rather than the middle, so year-to-date figures never have to be rebuilt from two sources. Export everything from the old system before you cancel it - registers, balances, documents, historical payslips - and store it somewhere your finance lead controls. Tell employees what changes for them and when, especially where payslips will now live. Keep the old system readable for a quarter afterwards. That overlap costs little next to reconstructing one disputed payslip from memory. Set the cutover date once, and then protect it.

Which HR stack fits which stage