I build automation that keeps running after the day it was built.

Cause: the address parser stopped early It read a web address up to the first ".co" it found, so a South African shop at dunns.co.za was being read as "dunns.co", which does not exist. Everything after that failed for the wrong reason, and the real problem, that my search was returning South African results instead of American ones, stayed invisible. Reading the whole address first, then filtering by country, made the actual problem obvious in one run.

Cause: the test asked the wrong question It looked for a few clothing words anywhere in a catalogue. A roaster selling three branded t-shirts cleared that easily, and so did a gift shop selling cotton napkins. Counting product by product and requiring most of the catalogue to be clothing fixed it. The lesson generalises: a check that scans for the presence of something will always be looser than a check that measures how much.

Cause: one step was running once per row It was reading the same sheet once for every incoming item. At fifteen rows nobody noticed. At sixty-seven it exceeded the allowed requests per minute and stopped. The fix was one setting, but the useful part was recognising the shape: a failure that arrives with growth rather than with a change, and would have returned at a hundred rows if I had only cleared the error.

Cause: nothing checked whether the result made sense The collector took the first plausible looking address it found on a page. Sometimes that was placeholder text left in a template. Sometimes it was a phone number and an address run together. Once it belonged to an entirely different business. Adding a validation step that rejects placeholders outright, and flags anything sitting on a domain that does not match the site it came from, turned silent bad data into a visible note I could act on.

Cause: expensive work happening before cheap work Every site was getting a second request to check its trading currency, including the great majority that had already failed on price or size. Moving that request so it only runs on sites that passed everything else cut the outbound calls by roughly ninety percent, with no change to the result. Ordering checks from cheapest to most expensive is free performance, and it is almost always available.

Cause: numbers that were not numbers, and dates read backwards Quantities had arrived as text, and dates in day-month-year order were being read as month-day-year, so most rows fell outside the reporting week. Neither threw an error. Both produced a confident, wrong answer. Every reporting engine I build now opens with a data quality check that runs before anything is calculated, because output that looks finished is more dangerous than output that fails.