Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Certification expiry tracker series ~6 min read

A certification expiry tracker on AWS for a few dollars a month

A qualification lapsing is one of the few small-business problems that is both entirely predictable and routinely disastrous. The date was known two years in advance. Nobody was watching it. On Monday somebody drives to a site, cannot get through the gate, and a day of work evaporates for a certificate that costs ninety pounds and takes a morning. This post walks through a small system whose whole job is to make that Monday impossible.

Woman in pink holding colourful files and office supplies
Photo by Cabri Caldwell on Unsplash

Key takeaways

  • One action to register a ticket: photograph the card. The date is read from it.
  • Lead times belong to the certification, not the calendar. Three months for some, three weeks for others.
  • Chasing escalates: the holder, then their manager, then whoever schedules work.
  • An expired ticket does not disappear. It stays visible and loud until it is replaced.
  • 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: a card photograph in, a dated register, renewal chasing outThree boxes across the top sit outside the AWS account. On the left, Card photo: taken by the person who holds the certificate. In the middle, Certification list: the types of certification your business needs and the lead time each renewal requires. On the right, Holder and manager: the people chased, in that order. Each connects by an arrow to the AWS account container below. Photographs flow down into the account. The certification list feeds in lead times. A renewal request goes back out. Inside the AWS account are three components in a row. On the left, the Reader, which pulls the certification type, the holder, the expiry date and the certificate number from the photograph. In the middle, the Register, holding one row per person per certification. On the right, the Chaser, which starts at the lead time appropriate to that type. A note at the bottom says it records what it was shown and never asserts that anyone is qualified.AWS ACCOUNTCard phototaken by the holderCertification listtypes and lead timesHolder + managerchased in that orderReadertype, holder,expiry, numberRegisterone row per personper certificationChaserat the lead timefor that typephotographslead timesrenew this, bywhenIt records what it was shown. It never asserts that anyone is qualified.
Fig 1. Three things outside the account, three pieces inside it. The certification list is what makes the chasing sensible: it holds how long each kind of renewal actually takes.
  • Database
  • Machine learning
  • Front-end & mobile
  • People

What you set up once (the outside)

  • A certification list. The kinds of ticket your business actually needs, each with the lead time its renewal takes and who at your end owns it. This is a short list — most businesses need eight to fifteen types — and getting the lead times roughly right is the single decision that determines whether the system works.
  • A way to photograph a card. A link on a phone. Somebody starts, or renews, and takes a picture of the card. Covered in Part 2. No typing, because a system that asks a site electrician to type a fourteen-digit registration number will contain about half the certificates it should.
  • A staff list with managers. Who holds what, and who to escalate to. Most businesses have this; the system reads it rather than owning it.

What runs on every ticket (the inside)

  • The reader. Pulls four things off a photograph of a card: the type, the holder’s name, the expiry date and the certificate number. Cards are wildly inconsistent — different awarding bodies, different layouts, dates in three formats — so the type is matched against your list rather than read freely, and an unreadable expiry is a question rather than a guess.
  • The register. One row per person per certification, holding the current card, its expiry, its number and the photograph. A renewal replaces the row’s dates and keeps the old card in the history, because “was this person certified on the 14th of March” is a question that gets asked after an incident.
  • The chaser. Works backwards from the expiry by the lead time for that type, then escalates on a schedule. Most of the design is here, because the difficulty is not knowing the date — it is getting somebody to act far enough ahead.

One certificate, end to end

One certificate from photograph to renewal, in five stagesA horizontal row of five boxes joined by arrows. Photographed: by the person who holds it. Read: the type, name and expiry are extracted. Registered: one dated row. Chased: starting at the lead time for that type. Replaced: a new card is registered and the old one is kept. A note says the fourth stage may be a year and a half after the third, and that this is the point.ONE CERTIFICATE, END TO ENDPhotographedby the holderReadtype, name, expiryRegisteredone row, datedChasedat the right lead timeReplacednew card, old keptThe fourth stage may be a year and a half after the third. That is the point.
Fig 2. The same system as one line. The gap between registering a card and chasing it is often years, which is exactly why a human process fails at it.
  • Database
  • Machine learning
  • Front-end & mobile

In plain words

A new site operative joins in March 2025. On his first morning he photographs three cards: a CSCS-style site card expiring May 2027, a first-aid certificate expiring September 2026, and an abrasive wheels ticket expiring March 2028. The reader gets all three, matches each type against your list, and writes three register rows. Total elapsed effort: about forty seconds, on his first morning, when he has the cards in his wallet anyway.

Eighteen months pass. In June 2026 the chaser looks at the first-aid certificate, which expires in September and whose lead time is set at ninety days because getting onto a course near you takes a while. It messages him: first aid expires 12 September, here is what you need, please book it. He does not reply. Two weeks later it messages his supervisor as well. The course happens in August, he photographs the new card, and the register updates. The alternative version of this story ends with him being turned away from a site in September and a day of work lost, and the only difference between the two is that somebody was watching a date.

Design rules that shaped every decision

  • The lead time belongs to the certification. A medical takes months and a toolbox talk takes a week, and one reminder schedule cannot serve both.
  • One action to register: photograph the card. Any typing at all and the register will be incomplete, which is worse than not having one.
  • It records; it does not verify. A photograph of a card is evidence of a card, not proof of a qualification, and the system says so.
  • An expired ticket stays visible. It does not archive itself, go grey, or drop off a list.
  • Escalate to a person, never to a group. A message to a team address is a message to nobody.
  • Keep the old card. “Were they certified on the day of the incident” is the question that eventually gets asked.

Why this shape

Every business with certified staff already knows the dates. They are in a spreadsheet, or in a folder of scans, or in the HR system. The data is not the problem. The problem is that acting on a date eighteen months out requires somebody to open the spreadsheet on the correct Tuesday, and nobody does that, and the failure is silent until a gate.

So the design puts nearly all of its weight on the chasing and the lead times, and almost none on the register, which is a table anybody could build. Reading the card from a photograph exists purely to make registration cheap enough that the register is actually complete — because a tracker that knows about eleven of your fourteen certifications gives you confidence about the three it will not save you from.

The next four posts walk through each piece: how a card gets read, how the register handles renewals and history, how the chasing escalates, and what the compliance view shows. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts