Case 01
A paper booking process, gone
A media department was lending several hundred pieces of camera, audio and lighting kit across three campuses using a paper diary, a shared inbox and a laminated sheet on the store door. Nobody could answer "is this free next Tuesday?" without walking to the cupboard.
The problem
Three campuses, one pool of equipment, and no shared view of it. Staff were double-booking cameras for the same shoot day. Kit went out and quietly didn't come back, and nobody noticed until someone needed it. Chasing overdue items meant reading back through weeks of email.
The department didn't want new software to learn, and there was no budget for a subscription. Whatever replaced the paper had to work on a phone in a store cupboard and be something the technicians could maintain without me.
Key decisions
Build it on Sheets rather than a real database
A proper web app would have been faster to write and nicer to use. It would also have left the department dependent on me and paying for hosting. Sheets meant they already had the accounts, already knew the interface, and could open the raw data and fix something at 8am without waiting for a reply from me.
Model filming days, not calendar days
A camera booked out on a Friday for a Monday shoot isn't overdue over the weekend. The first version treated every day equally and immediately generated a wall of false overdue flags that staff learned to ignore. Rebuilding the date logic around teaching and filming days made the overdue list short enough to actually be worth reading.
Harden the backend after a data loss incident
Part way through rollout, bookings started corrupting. The cause turned out to be an old deployment URL still live alongside the current one, with two versions of the script writing to the same sheet. I traced it, retired the stale deployment, and added validation and an append-only change log so that a bad write can now be identified and reversed rather than silently overwriting good data.
Outcome
The paper diary is gone. Overdue chasing is a list rather than an archaeology exercise, and the technicians have made their own changes to the system since handover without needing me.
[Placeholder — ask the department for two sentences. Do not publish this page with invented copy here.]
Role, department
What I'd do differently
I'd have checked for stale deployments before going live rather than after. It's a five-minute check and it would have prevented the only serious incident in the project. It's now on my pre-launch list for anything running on Apps Script.
Next case