BuzbyTimeRead the requirements guide

Choosing and running the software · 4.6

Building it yourself

Building it yourself. What decides it, what it costs, and what usually goes wrong. For another implementation reference, see Monitask's reference.

It looks like a table of durationsThe temptation

A start, an end, a person, a category. Any competent developer can build that in a week, and that week is genuinely enough for the part everybody imagines.

Which is why this gets built, and why it gets abandoned about two years later. For another perspective on the surrounding workflow, see Intercom.

What actually takes the time

  • Offline capture and conflict resolution when a device reconnects.
  • Time zones and daylight saving, which are harder than they look and produce wrong payroll when they are wrong.
  • Rounding and overtime rules, which differ by contract and by jurisdiction.
  • Approvals and corrections, with an audit trail.
  • Access control, so that people see their own records and not everybody's.
  • Retention and deletion on a schedule, including backups.
  • Integrations, and their failure handling.
  • The export somebody can read in five years.

None of that is on the first sketch and all of it is required before the thing is trustworthy.

Daylight saving in particular

A shift crossing the change is either an hour longer or an hour shorter, the answer differs by jurisdiction and by contract, and getting it wrong appears as an unexplained payroll discrepancy twice a year.

It is a small thing and it is the specific small thing that makes people regret building.

The maintenance question

Who maintains this in three years, and what happens if they leave? If the answer is one named person and a shrug, the honest conclusion has already been reached.

Internal systems in this category are maintained enthusiastically for a year, adequately for another, and then by whoever inherits them without documentation.

Where building is actually right

Where the workflow is genuinely unusual and no product fits without more adaptation than construction would take. This exists and it is rarer than it feels during a frustrating evaluation.

The test: describe your requirement to three suppliers. If all three say it is unusual, it may be. If they all say it is standard and demonstrate it, the frustration was with the evaluation rather than with the market.

The spreadsheet answer

For a small team with simple needs, a shared sheet with a fixed structure is an entirely legitimate answer, and it is the one a supplier will never suggest.

It fails at scale, at offline, at access control and at audit trail. Below the point where those matter, it costs nothing and it works, and an organisation should reach for software when it hits one of those limits rather than before.

The middle path

Buy the recording and build the reporting. The hard, unglamorous, regulated parts are the ones a product solves; the analysis specific to your business is the part worth writing yourself, and a decent export makes that possible.

The half-built version

The worst outcome: something started internally, adequate for the demonstration, never finished, and now relied on for payroll. It works until a rounding rule changes or its author leaves.

If you have one, either finish it properly with the list above or replace it. Continuing is a decision being taken by default.

Cost, honestly compared

Price the internal build at the loaded cost of the people, including three years of maintenance at some fraction of a role. Compared like that, the build is rarely cheaper, and the comparison is almost never made that way because internal time is invisible in most budgets.

What building teaches you

Occasionally worth it for that alone: a team that has attempted the rounding rules and the offline conflicts understands the problem well enough to evaluate products properly.

That is an expensive education and it is a real one.

A closing thought

The recording is regulated, fiddly and identical everywhere. The analysis is specific to you and is where the value is. Buy the first, build the second, and insist on an export that makes the division possible.

The questions to answer before writing code

  • Who maintains this in three years?
  • What happens to payroll if it is wrong for a month?
  • Who writes the retention and deletion logic?
  • Who answers an access request against it?
  • What is the export, and who has tested it?

None of these is technical and all of them are the reasons internal builds in this category fail. Answer them in writing before starting, and the answer to the overall question is usually clear by the third one.

Buying the boring part

The regulated, fiddly, identical-everywhere part is the part with the least competitive advantage in it. Nobody has ever won business because their internal timesheet handled daylight saving elegantly.

Which is the general argument for buying here, and the same argument identifies what to keep: the analysis, the categories and the questions, all of which are yours and none of which requires building a recording system to own.

Where to start

Write the eight items from the second section on a sheet and estimate each honestly. The list is the decision; the estimate merely confirms it.

One line to carry

The easy week of building is real, and so are the eight things that come after it. Buy the recording, build the analysis.

If you decide to build anyway

Start with the export. A system whose data can be taken out cleanly can be replaced later without a crisis, and building that first is the single decision that keeps the option open.

Also in choosing and running the software