Know before your clients do.

Every site I look after gets the same three questions after an update. 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.

Checks, not memory

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

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:

• What a staging site really sends and how to keep it from reaching real people.
• The update that broke the contact form while every page still loaded.
• The .env file anyone could download.

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