What happens if the automation breaks after the project ends?

Question

VX-N · Accepted Answer

You own the code and the accounts, so you are never locked out of your own system, and we are reachable. The larger protection is architectural: systems built on your own accounts with documented logic can be picked up by any competent developer, not only by us. Integrations do break — APIs change, credentials expire, vendors deprecate endpoints, a third-party service has an outage and your workflow inherits it. The question to ask any builder is not whether it will break but who can fix it if they are unavailable. If the answer is 'only us', you have bought a dependency rather than a system, and the price of that dependency is set later, when you have no alternatives. The failure that actually costs money is not the loud one, it is the silent one: a sync that stops and nobody notices for three weeks, while leads pile up unrouted or invoices go unsent. Silent failure is a design choice, and the antidote is built in from day one — every workflow reports that it ran, and someone is notified when it did not. The distinction matters: a check that says 'the last run succeeded' is different from one that says 'a run happened when it should have'. Workflows that fail by never firing are invisible to success-based monitoring, which is why the check should watch for expected activity, not just absence of errors. Most post-project breakage traces to a small set of predictable causes, and each has a cheap pre-emption: credentials and API keys expire, so they get logged with renewal dates and owned by your accounts rather than a developer's personal login; vendors deprecate API versions with notice, so the notices need to arrive at an inbox someone reads; and the person who knew how it worked leaves, so the logic is documented in plain language — what triggers what, where the data goes, what to check first when it stops. That last document is the difference between a two-hour fix by any competent developer and a two-week archaeology project. On the relationship itself: some clients want ongoing support and some want to be handed the keys, and both are legitimate ends to an engagement. What we do not do is make ourselves structurally necessary — the system runs on your accounts, the logic is documented, and the stack is standard, so support is something you can choose to buy rather than something you are forced to. When something does break, you are not starting from zero with us either: we built it, the context is retained, and reachable means reachable.