Why we built our own HRIS instead of buying one

When I joined a foreign insurance startup in Riyadh as HR Lead there was no HR system. Records lived in folders, attendance in a spreadsheet, and payroll inputs were assembled by hand every month. The obvious move was to buy an HRIS. We did not, and I would make the same decision again.

What the demos had in common

Every vendor demo showed a system built for a company much larger than ours. Modules we would not touch for years. A per-employee price that assumed we would grow into it. An implementation project measured in months, with a consultant to configure workflows we did not have yet.

None of this was the vendors' fault. Their products are designed for companies whose processes are stable. Ours were being written at the same time as the first policies. Configuring a large system around processes that change every month is slower than not having the system at all.

What we actually needed

When I wrote down what the spreadsheets were failing at, the list was short. Three things, in this order:

• One record per employee, with document expiries that warn us before the residency platform does. Passports, residence permits, contracts and insurance cards all expire on different dates, and a missed expiry becomes a government problem rather than an HR one.
• Attendance and leave that employees can see and managers can approve without email. Most HR email traffic at a small company is leave requests and balance questions.
• Clean payroll inputs at the end of the month. Every absence, allowance and change in one place, so the payroll run starts from data rather than from reconciliation.

Everything else on the vendors' feature lists was either years away or already handled well enough by the government platforms we had to use anyway.

Building it

With AI-assisted development, a small custom system around exactly those three needs took weeks rather than months, and the company owns it. The data model matches how we work, not how a vendor thinks a company like ours should work. When a process changed, the system changed with it the same week.

Two things made this possible. The first is that the scope was tiny on purpose. The second is that the person specifying the system was the person who would run it, so there was no translation layer between what HR needed and what got built. Most failed HR system projects fail in that translation.

The same approach later gave us a learning platform for onboarding and compliance training, built around our roles and our content rather than a generic catalogue.

What I would tell another HR lead

Buy a system when your processes are stable and your headcount justifies the price. Before that, build the smallest thing that removes the spreadsheets. You will understand your own processes far better by the time you do buy, and you will configure the big system in weeks because you already know what you need.

For a foreign company setting up in Saudi Arabia, this matters more than it looks. Every government platform you register on will ask for the same employee data in a slightly different shape. A single source for that data, however small, is the difference between a payroll run that takes an afternoon and one that takes a week.