Building Your Own

A form with a start time, an end time and a project code looks like a week of work. That part is a week of work. It is not the system.

What the estimate usually covers

The entry form.

A list view.

An approval step.

An export.

Four things, and they are genuinely quick.

What it misses

The rule engine. Overtime thresholds by jurisdiction and agreement, break handling, premiums, minimum call-out, rest periods. This is most of the work and it changes with legislation.

Time correctness: midnight crossings, daylight saving, multiple zones, week boundaries that differ by pay group.

The audit trail, which must be complete and immutable.

Retention and deletion, per data category, enforced and verifiable.

Worker self-access, which in several jurisdictions is part of the legal standard.

Recalculation of a closed period after a rule correction, preserving the original.

Bulk correction.

Offline operation for anyone not at a desk.

Integrations, each with its own failure handling.

Subject access, export, and everything else in this collection.

None of these is hard individually. Together they are a product, and they are why the products cost what they cost.

The maintenance nobody estimates

Legislative changes, indefinitely.

Payroll vendor format changes.

Browser and mobile platform changes.

Security patching.

Someone available at period close, every period, for years.

A built system with no maintainer is worse than no system, because payroll depends on it.

Where building is defensible

A genuinely unusual model that no product serves — an unusual unit of work, an exotic rate structure — and only where that oddity is central rather than incidental.

A thin layer over a product's API, which is a different proposition: the rules and compliance stay with the vendor and you build only the entry experience your people need. This is frequently the right answer when the complaint is usability rather than capability.

A small, stable team with no payroll dependency, where the record is for costing only and an error costs a report rather than a payslip.

Where it is not

Because the quotes look expensive. Compare against three years of a developer's time, not against the licence alone.

Because the product is 90 percent right. The missing ten percent is usually the rule engine.

Because nobody will own the vendor relationship. Nobody will own the built system either, and that outcome is worse.

Cost it against three years of a developer

The comparison that makes the decision honest.

Not licence against zero.

Licence and implementation against build, plus maintenance indefinitely.

Maintenance includes legislative changes, payroll format changes, platform updates, security patching, and someone available at every period close.

A built system with no maintainer is worse than no system, because payroll depends on it, and that is the outcome when the original developer moves on.

The middle path

Frequently the right answer and rarely the one proposed.

Buy the record and the rule engine; build the entry experience against the API.

The compliance surface stays with someone who maintains it through legislative changes indefinitely.

You control the part your people touch, which is where the usability complaint actually lives.

Ask whether the API supports it before assuming: it needs write access, validation parity and audit-trail equivalence.

Account for the connection layer

Before building a connector that must be owned indefinitely, compare it with the available options and price ongoing monitoring, retries and vendor changes.