Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Asset register keeper series ~6 min read

An asset register keeper on AWS for a few dollars a month

The register lists four hundred and eleven items. A walk round the building finds three hundred and forty of them, twelve things that are not on it at all, and a storeroom of equipment that was replaced in 2021 and never removed from anything. Nobody has done anything wrong; there is simply no moment at which disposal gets recorded.

A group of tall metal structures sitting on top of a body of water
Photo by Julia Taubitz on Unsplash

Key takeaways

  • Registers drift because acquisition has a trigger and disposal has none.
  • Decide which of the four purposes you are serving before choosing fields.
  • Verify by sampling continuously, not by auditing annually.
  • A physical label on the thing is unglamorous and is most of the solution.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: assets added, moved, disposed and verifiedThree boxes across the top sit outside the AWS account. On the left, Purchases: invoices over a threshold. In the middle, The things themselves, with labels on. On the right, Whoever asks: insurance, finance, or somebody wanting to know where something is. Each connects by an arrow to the AWS account container below. Acquisitions flow down into the account. Labels scanned feed in. A register that is true goes back out. Inside the AWS account are three components in a row. On the left, Add, which is nearly automatic. In the middle, Move and dispose, the hard part. On the right, Verify, by sampling continuously. A note at the bottom says the middle box is where every register in the world fails.AWS ACCOUNTPurchasesinvoices, overa thresholdThe thingswith labels onWhoever asksinsurance, finance,or 'where is it?'Addnearly automaticMove and disposethe hard partVerifyby sampling,continuouslyacquisitionslabels scanneda register that istrueThe middle box is where every register in the world fails.
Fig 1. Three things outside the account, three pieces inside it. Adding assets is easy and is not where registers go wrong.
  • Compute
  • Machine learning
  • Front-end & mobile
  • People

The asymmetry

Buying something produces an invoice, a payment, a delivery and a person who wanted it. There are several natural moments at which it can be added to a register and at least one of them usually happens.

Disposing of something produces nothing. A laptop goes in a cupboard, a machine is taken away by a scrap merchant, a monitor stops working and is put in a skip. None of those events touches finance, none of them generates a document, and none of them causes anybody to open the register.

What runs (the inside)

  • Add. Driven from purchasing above a threshold, with a label printed. Part 3.
  • Move and dispose. Making both take seconds, because anything slower does not happen. Part 3.
  • Verify. Sampling a portion continuously so that drift is measured rather than discovered. Part 4.

One asset, end to end

One asset from purchase through to disposalA horizontal row of five boxes joined by arrows. Invoice over five hundred pounds, flagged. Label printed and stuck on. Scanned into a room, one tap. Moved twice, scanned each time. Disposed in 2029, scanned out with a reason. A note says every step is a scan, and typing anything at any point is where this breaks.ONE ASSET, END TO ENDInvoice over £500flaggedLabel printedand stuck onScanned into a roomone tapMoved twicescanned each timeDisposed 2029scanned out, with a reasonEvery step is a scan. Typing anything at any point is where this breaks.
Fig 2. The same asset as one line. The whole lifecycle is barcode scans because a register maintained by typing is a register that is not maintained.
  • Compute
  • Machine learning
  • Front-end & mobile

In plain words

An invoice comes in for a piece of equipment above the threshold. It is flagged, a label with a code is printed, and somebody sticks it on the thing when it arrives and scans it into a location. That takes about twenty seconds and it is the whole acquisition process.

Over the next few years it moves twice, and each time somebody scans the label and picks a new location from a short list. In 2029 it is replaced, and whoever removes it scans it and picks a disposal reason: scrapped, sold, traded in, stolen, lost.

Meanwhile, every month a handful of assets are sampled: a list of twenty appears on somebody’s phone, they go and look, and they confirm or correct. That is the verification, and it produces a measured accuracy figure rather than an annual surprise.

Design rules that shaped every decision

  • Decide the purpose first; the fields follow from it.
  • Disposal must be as easy as acquisition, or the register only grows.
  • Physical labels on things. There is no software substitute.
  • Sample continuously; never plan an annual full count.
  • Record the accuracy figure and watch it, rather than assuming.
  • A missing asset is a state, not a deletion.

Why this shape

Asset registers are usually built as a finance artefact and then asked to do three other jobs badly. The result is a spreadsheet with a purchase price, a depreciation calculation, a serial number and a location field that has said “main office” for six years.

Deciding which purpose dominates, and being explicit that the others are secondary, produces a register that is genuinely useful for one thing rather than nominally useful for four.

The next four posts walk through each piece: what the register is actually for, how things get onto it and off it, how it gets verified without a full audit, and what a good register tells you. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts