How to know nothing broke
Ask for the list of what already worked, and that same list checked after the change. If they cannot show it to you, the change is not verified.
Ask for two things: the list of what already worked before anything was touched, and that same list checked afterwards. If they cannot show it to you, the change is not verified — it was eyeballed, which is a different thing. And I say this from experience: it happened to me on this very site, with a check in place.
Why «it compiles» and «it looks fine» are not enough
I was adding a new page here. To integrate it I had to touch two pieces used by all eight pages of the site: the top menu and the language switch. Before starting I put a check in place: confirm that the files of the two home pages did not change a single line. If they do not change, I reasoned, they cannot have broken.
The reasoning was wrong. The change was not in those pages: it was in two pieces they use. A file can stay untouched and behave differently, because what changed is something it depends on.
What I believed
The home page files did not change, so they did not break.
What turned out to be true
I broke a piece on purpose to see what my checks would say: the project compiled without a single error, the data search engines read stayed identical, my check stayed green — and the site's navigation was broken.
What actually counts as proof
The fix was not looking harder: it was measuring something else. Now, before touching anything, I record where every link on the working pages actually goes —the logo, each menu item, the language switch, the contact button— and after the change I read them again and compare one by one.
And there is a second step I never skip: I break a piece on purpose and confirm the check turns red. If it does not turn red, the check is useless, and I fix it before carrying on.
A check that stays green with the defect in place is worse than no check at all. It does not just fail to warn you: it convinces you everything is fine.
Three answers that are not a verification
- «It compiles with no errors» — that only says the code is valid, not that it does the right thing.
- «I never touched that file» — that says nothing if what changed is something the file depends on.
- «Look, it looks fine» — a screenshot does not tell you where the links go.
All three can be true with the site broken. The only thing that works is comparing behaviour against how it was before, and proving that comparison is capable of failing.
Where this hits you
The most expensive case I know is a travel agency adding a section to its site and, with nobody noticing, leaving the contact form broken. No error appears — silence appears. Enquiries simply stop arriving, and that gets discovered weeks later, counting how many came in last month. If you work with bookings and quotes, in systems for travel agencies I explain how I put that part in order.
The same goes for any change to something that is already bringing you clients: the risk is not in what gets added, it is in what gets touched along the way.
The question, in one line
When you hire someone for a change, the most useful question is not how long it takes. It is: «how will you prove you did not break what already worked, and how do I know that proof works?».
If they answer with a concrete list and with evidence that their check can fail, you are in good hands. If they answer «relax, I did not touch anything», write down the date: you are going to need it.
And if what is coming is not a single change but automating a whole process, there are four other questions worth having ready first: what to ask before automating.