All notes

Know before your clients do.

The quiet failures a client finds first. Why I turned my after-update checks into free, open-source tools.

2 min read

Every site I look after gets the same questions around an update. Before it: what will this update really change? Is my staging a safe copy to try it on? After it: is it safe? Did the change break anything? Is it still saying what it should?

For years I answered them by hand. I clicked through pages, filled in forms and waited. The loud failures got caught. A white screen gets noticed in minutes.

The quiet ones did not. A plugin update stops the email to the shop owner while the form still says thanks. A staging copy of a live shop sends a test order confirmation to a real customer. A backup of the site's config sits in a public folder for months. None of these raise an error. Someone outside finds them first. Usually it is a client.

Here is that afternoon on a made-up shop. Run the update, then ask the three questions that come after it.

Try it

The update that looked fine

Run the update. The loud failure shows itself. Then ask the three questions and see what stayed quiet.

beanandleaf.test

Bean and Leaf

Coffee, roasted every Monday

House blend, 250 g

£9.50

Add to cart

Contact us

When does my order ship?

Thanks. We will reply within a day.

A made-up shop, before its update.

Loud, caught at once

0 / 1

Quiet, found by asking

0 / 3

Run the update first

A simulation of the pattern, not a real system.

Checks, not memory

The answer was not more care. It was a check that runs the same way every time.

Read the update before you install it. Try it on a copy with no real customers in it. Take a snapshot before the change. Run it again after and show only what is different. Ask the site what it sends instead of trusting that it sends it. Look at the site the way a stranger would before a stranger does.

It is the same question I ask of every system: what happens when this fails? These tools ask it of a website after every change.

Why open source

Agencies and freelancers run these checks on client sites. That only works when they can read every line, run it on their own machine and keep their clients' data there. So the tools are free, they run locally and the source is public.

They also get better when people use them on sites I have never seen. Every missing check someone reports becomes a test case.

What this series covers

Each tool gets a note of its own, about one real problem it catches:

The tools, the one-line install and their live output are on the open source page.

Next

Here is what I would do next

  • Install the set on the machine you deploy from.
  • Read your next plugin update with Sightread before you install it.
  • Run Tuner on one site you own and fix the first critical finding.
  • Take a Soundcheck snapshot before your next plugin update and compare after it.
  • Seal your staging site with Echo before you test the next email change.

Have a workflow like this?