A founder I spoke with last weekend had a question that I hear regularly: "What happens when it breaks?"
They were not being sceptical. They had seen enough technology projects go sideways to know that things break, and they wanted to understand what they were actually signing up for before committing to building a system they would depend on.
It is the right question to ask. And the honest answer is that the maintenance plan is not a separate conversation from the build. It is part of the design. A system that does not account for how it will be monitored, maintained, and recovered when something goes wrong is not a finished system. It is a demo with a deployment date.
Why things break, and when
Automation systems break for predictable reasons. Understanding those reasons is the first step to designing around them.
Third-party APIs change. A webhook integration that worked perfectly for six months breaks the day the external service updates their response format. If you are not monitoring for this, you find out when a client mentions they have not received a follow-up in two weeks.
LLM behaviour drifts. A prompt that produced reliable output in testing starts producing edge-case failures at scale. The model has not changed, but the real-world input distribution is messier than the test data. Without output validation in the workflow, those failures propagate silently downstream.
Business logic changes. A new service is added. A pricing tier is updated. A team member changes the way they name things in the CRM. Any of these can break a workflow that was built around the old logic, and none of them are bugs in the traditional sense. They are just the reality of a business that is moving.
Volume surprises the system. A campaign runs, inbound spikes, and a workflow that handled 20 leads a day starts receiving 200. Rate limits hit. Queues back up. Data arrives out of order. Systems that were never stress-tested under load reveal their assumptions.
"Most issues require small adjustments, not complete rebuilds. The ones that become complete rebuilds are the ones that were never monitored."
What a real maintenance plan looks like
Every system I deliver has four layers of maintenance built in from the start. These are not afterthoughts bolted on before handoff. They are designed into the architecture.
Error handling on every critical node. Every step in a workflow that can fail needs a defined failure path. Not a generic error that halts execution, but a deliberate route to somewhere useful: a retry queue, a fallback value, or a human escalation. When something goes wrong at 2am, the system handles it and logs what happened rather than silently stopping.
Alerting that goes somewhere real. Errors need to reach a person who will act on them. For most clients I build for, that means a Slack channel dedicated to system alerts. A critical failure fires a notification with the workflow name, the error, and the affected record. The team sees it first thing in the morning rather than discovering it from a client complaint three days later.
Execution logs for every run. Every workflow execution writes a record: timestamp, inputs received, output produced, success or failure. Those logs sit in Airtable or a Google Sheet. If a client says something felt off last Tuesday, I can pull the log for last Tuesday and see exactly what happened, what data came in, and what the system did with it.
A 30-day post-launch monitoring window. The first month of a production system is when most of the real edge cases surface. Real data is messier than test data. Real users do things you did not anticipate. I watch the logs actively during this period and fix anything that surfaces under real conditions before handing it over fully. This is not a support contract. It is part of the delivery.
What the client needs to be able to do
A system the client cannot understand is a system they cannot maintain. Part of what I deliver at handoff is not just documentation but the capability for the team to handle the most common maintenance scenarios themselves without needing to call me.
That means walking through the workflow architecture in a live session, not just sending a document. It means explaining what each error alert means and what the first response should be. It means making sure the execution log is readable by someone who was not involved in the build.
- Can they identify which workflow failed? The alert should name it clearly.
- Can they see what data was involved? The log should show inputs and outputs.
- Do they know who to contact if they cannot fix it themselves? Escalation path documented.
- Can they update simple things without breaking complex things? Documented change boundaries.
- Do they know what normal looks like? Baseline metrics for a healthy week of runs.
A client who can answer yes to all five of those is a client who owns their system rather than depending on me indefinitely. That outcome is the goal of a good handoff.
The mindset shift
Most automation projects are considered done at delivery. The build is finished, the demo runs cleanly, the invoice is paid. What happens six weeks later when the first real breakage occurs is treated as a separate problem.
The better framing is that delivery is the beginning of a system's life, not the end of a project. The system will encounter data it was not built for. It will face conditions that did not exist in testing. The third-party APIs it connects to will evolve. The business it serves will change.
A maintenance plan is not pessimism about the build. It is realism about what production means. A system that is monitored, logged, and recoverable is a system a business can actually depend on. A system that is none of those things is a liability waiting for the right edge case to expose it.
When a founder asks me what happens when it breaks, the answer I want to give them is: you will know about it before it affects a client, the log will tell you exactly what happened, and most of the time the fix will take ten minutes. That is only possible if you designed for it from day one.