How we test changes before they go live on your site
Every change travels our release path before visitors see it, most of it automatic. What runs, what a human looks at, and why it takes minutes.
The short answer
Every change to a site we look after, from a typo fix to a redesign, travels the same path before visitors see it: automated build and type checks, content and link validation, a preview deployment on the real infrastructure, automated visual and accessibility checks, a human look on a phone, and a deploy that can be undone in one step. Most of it is machines and takes minutes. The human step is short because the machines have already caught the mechanical problems. Exceptions to the path are how sites break on Friday afternoons, so there are none.
This is the release path for a site that is already live. A new project is a different route: it runs through the phases of the project process and passes the eight-step quality check before hand-over.
The release path
| Step | What happens | Catches |
|---|---|---|
| 1. Build and type checks | The site is built from scratch on a clean server; code and templates are type-checked | Broken code, missing files, mismatched data, a page that would crash |
| 2. Content and link validation | Every content file is checked against its schema; internal links and image paths are verified | Missing fields, wrong dates, dead links, missing images |
| 3. Preview deployment | The whole site, with exactly this change, is published to a unique link on the same platform as production | Anything that only shows on real infrastructure: headers, redirects, caching, integrations in test mode |
| 4. Automated page checks | Every affected page is loaded at desktop and mobile sizes; accessibility, overflow, console errors and structured data are checked | Layout breaks on phones, contrast failures, script errors, broken metadata |
| 5. Human look | The preview is opened on a phone and a desktop by a person, and by you where the change needs your approval | What machines cannot judge: is it right, is it clear, does it read well |
| 6. Reversible deploy | The approved build becomes production in one atomic switch; the previous build stays available | Whatever slipped through, undone in a minute |
Why the path is the same for every change
- Small changes break sites too. A typo fix in the wrong file, a paste with invisible characters, a link with a missing letter. The checks cost minutes and catch them.
- Habits survive pressure; judgement calls do not. A path with no exceptions is followed at 5 p.m. on Friday. A path with exceptions is skipped exactly then.
- The record is complete. Every change has a preview link, a check result and an approval. When something is questioned later, the history answers.
What you see
For changes you asked for: a preview link, usually within the hour, to open on your phone. You approve or comment. Then a note that it is live. For maintenance changes: a line in the monthly report. For anything that went wrong and was rolled back: an incident note with cause and prevention. The path is designed so you see the result, not the machinery.
What this means for you
Changes to your site should be boring: checked by machines, previewed on real infrastructure, looked at on a phone, deployed in one reversible step. Minutes, not days, and no exceptions for small edits. If your current setup edits production directly, that is the risk to fix first, before the next Friday afternoon.
Frequently asked questions
Does this slow down small changes?
By minutes, not days. The automated checks run in the time it takes to make coffee, the preview link is ready when they finish, and a text change is approved on a phone in seconds. Skipping the path saves those minutes and costs the occasional broken page in front of customers.
Can we approve changes ourselves?
Yes, that is what the preview link is for. You open it on your phone, see exactly what visitors will see, and approve or comment. Nothing goes live until the approval, for changes where you want that gate. Routine maintenance can be approved by the partner under the agreement.
What if something still breaks after all this?
It is rolled back to the previous version in one step, usually within a minute of monitoring noticing. Then the cause is found, a test is added so that class of problem is caught next time, and the change goes through the path again. Testing reduces incidents; rollback makes the remaining ones short.