Most automation dies in month three

There is a familiar shape to failed automation projects. The build goes well. The demo is good. It runs for a few weeks. Then something upstream changes format, the job fails silently, someone notices a week later that the numbers look off, and the team quietly reverts to the old spreadsheet while somebody files a ticket that nobody picks up.

The system is still there. It is just not being used, and eventually nobody remembers that it exists. On paper the project delivered. In practice it bought three weeks of relief.

Almost none of this is a build-quality problem. It is an ownership problem. The agency that built it has moved on to another client, the internal team never fully understood it, and the thing that would have saved it, someone noticing a failure within an hour rather than a week, was nobody's job.

The fixes are unglamorous. Alerting that goes to a human who is expected to respond, not to a channel nobody reads. Runbooks written for someone who did not build the system. A named owner who is still contactable in month six. Failure modes that stop loudly instead of continuing with bad data, because silent partial failure is far more damaging than a clean outage.

This is most of why we stay embedded and operate what we build. Not because clients cannot run it, but because the handover is where these projects usually die, and being the ones on the pager makes us build it differently in the first place.