The Automation Nobody Remembers Building

There was a thread on Hacker News recently asking what people run on a £5-a-month server that's worth keeping online around the clock. The answers were a mix of personal projects, but the question itself is the interesting bit. A lot of businesses have the same thing, just nobody thought to ask it out loud. Somewhere there's a script, a scheduled task, or a Zapier flow that's been quietly running for three years, doing something nobody could fully explain if you asked them tomorrow.

It's rarely dramatic. It's the nightly export that emails a supplier price list to the ops manager. The scheduled job that checks a shared inbox and forwards anything matching "invoice" to the bookkeeper. The small sync that keeps two spreadsheets roughly in step because someone got fed up copying rows by hand in 2023. None of it was ever commissioned as a project. It got built in an afternoon, it worked, and everyone moved on.

Why this is different from "proper" legacy software

I've written before about inheriting an undocumented system from a developer who's long gone. This is a smaller, quieter version of the same problem. Nobody commissioned it, so there's no brief, no invoice, no handover. It wasn't built by a developer who left the business, it was built by whoever was around and knew enough Python or had a Zapier login. That makes it easy to forget it's there at all, because there was never a moment where someone officially owned it.

The warning signs are usually small and easy to miss:

• A server, cron job or subscription nobody can explain on the monthly bill
• A process that "just runs" and only gets attention when it stops
• A login shared between three people, none of whom set the password
• A person who left the company eighteen months ago whose name is still on the automation

The actual risk isn't the £5 a month

Nobody's losing sleep over hosting costs. The risk is what happens the day it quietly stops working and nobody notices for a fortnight, or notices immediately but has no idea where to even start looking. A supplier price sync that silently fails means someone's quoting last month's prices. An invoice forwarder that breaks after an email provider changes its spam filtering means unpaid invoices nobody chased. None of these show up as an outage. They show up weeks later as a discrepancy someone finds by accident.

Compare that to a properly scoped automation. When I build something for a client, it comes with a clear owner, some basic logging, and an agreed answer to "what happens if this fails". That's not because the small stuff people build themselves is bad, it's because it was never built with failure in mind. It was built to solve today's annoyance, and today's annoyance didn't include "what if this breaks while I'm on holiday".

Finding out what's actually running

Most businesses have never done a proper audit of this. It's worth an hour of someone's time:

• Check the company card statement for small recurring charges you can't immediately place, hosting providers, VPS bills, automation platforms like Zapier or Make
• Look at who has admin access to those accounts, and whether they still work there
• Ask around: "does anyone know what sends that email every morning?"
• Check email forwarding and filter rules on shared inboxes, these are a common place for quiet automation to hide

You'll usually find two or three things nobody quite expected. That's normal. The point isn't to be alarmed, it's to know they exist before they become a problem.

What to do once you've found it

Not everything needs replacing. Plenty of small scripts are fine exactly as they are, they just need a paragraph written down somewhere: what it does, where it runs, who to call if it stops. That alone fixes most of the actual risk, because the problem was never the automation itself, it was the fact that knowledge of it lived in one person's head.

For the ones that matter more, where a failure would actually cost money or cause a visible problem for a customer, it's worth treating them properly. That means proper error handling, a log you can check, and an alert that fires if it stops running rather than silence being the only clue. This is the same thinking behind giving automation a proper business process automation build rather than a patched-together script, not because the script was wrong to begin with, but because it's outgrown being something nobody's responsible for.

The real cost of the £5 server

The HN thread was half a joke about electricity and VPS bills. For a business, the equivalent question is worth asking seriously: if this stopped tomorrow, would anyone notice, and would anyone know what to do about it? If the honest answer is "no" to either, that's the thing worth fixing first, not because it's broken, but because right now nobody actually owns it.