Workshop Diary is an ongoing series about how internal tools actually get built — out of ideas, mistakes and iteration. Part 1.

This story begins with an invoice. For years we had an external service that kept track of statutory obligations and reminded us of deadlines. A perfectly decent service. But as the renewal invoice approached, I stopped to ask myself the engineer’s basic question: what are we actually buying? The answer was a structured list and calendar reminders.

Meanwhile, audit preparation was what it is in many industrial companies: Excel files in different silos, documents whose currency nobody was quite sure of, and the same familiar routine two weeks before every audit. Can we find this? Who updated that? When did someone actually last look at this?

The best time to build your own tool is before the old one’s licence expires.

The idea was simple in the end

I decided to build my own annual clock: one system that knows what requirements we have, which document covers which requirement, and when each item is next due for review. Not just for the environment and safety side, but for every standard we live with — quality, environment, safety, information security.

Right at the start, an idea crystallised that carried the whole project, and that I’ll return to in part 5: the mere existence of a document proves nothing. You need three levels. The document exists. The document actually covers the requirement. And a human being has verified it. Most systems stop at level one — and that is exactly why audits surprise people.

What I learned first

The first lesson wasn’t technical. It was the realisation that replacing a purchased service is not a cost-saving project but an understanding project. When you build the requirement register yourself, you have to read every requirement and think about what it means in your everyday work. That work was worth more than any single feature I coded later.

In the coming parts I’ll tell you how this idea grew into a system — and where I tripped over my own cleverness. Next week, though, we change tools: a story about what it’s like to inherit another person’s code.