Freelancer disappeared and the automation broke: get access first

The automation ran fine for months. Then something broke, you messaged the person who built it, and got nothing. A week of nothing. Maybe one "busy right now, will look next week" that never turned into anything. Meanwhile the system is half working, you are not sure what it touches, and you are not certain you could even log in to look.

Of the six rescues we have scoped, three started exactly like this, with the builder gone and every account in his name. The situation is recoverable, and usually without starting over. But the order matters, and the natural instinct, which is to start fixing immediately, is the wrong first move.

When the freelancer disappeared, accounts come first

List every account the system could touch: the automation platform (n8n, Make, Zapier), hosting (a VPS, Railway, a cloud account), domain and DNS, the AI provider, databases, and every connected service such as the CRM, the calendar, and whatever sends email. For each one, answer a single question: can someone in your company log in today?

Usually the answers fall into a few groups. Accounts you own where the builder had access are the easy ones. Change the passwords, rotate the API keys, remove their user, done.

The dangerous group is accounts in the builder's name running your business. The workflow lives in their n8n or Make account, or the OpenAI key is on their card. If they stop paying, or their trial converts, or they delete the account in a fit of tidying, your automation vanishes with no notice at all. Send one clear message: transfer ownership or export the workflows, here is payment for an hour of your time, here is the date. A surprising number of vanished freelancers will do this one task, because it closes the relationship cleanly. And if they are truly gone, the export matters less than it feels like it should. The connected services are yours. A rebuilt workflow pointed at your CRM and your calendar recovers everything except the logic, and the logic is what the documentation step is for.

Then there are the accounts you suspect exist but cannot find. Search company inboxes for signup and invoice emails from the usual platforms. Billing emails are the map of your own system.

Do all of this before touching anything technical.

Add eyes before you add fixes

Right now you cannot see what the system is doing, so you cannot tell whether a change helps or hurts. Logging, alerting and a named reader sit in the middle of the production-ready checklist, and an inherited system usually fails all three. Before the first fix:

• Turn on execution logging in the platform and check the retention setting. Some keep failed runs for a few days only.
• Route failures to a Slack channel or an inbox that a person reads daily, and confirm that someone does.
• Write down the current failure rate: runs per day, failures per day. This is your baseline. A week from now it tells you whether things are improving, and today it tells you whether the system is mostly healthy or mostly broken, which changes what to do next.
• Screenshot every workflow before you change it.

This feels like a delay. It is the opposite: the first time a fix quietly breaks something else, and in an undocumented system it will, the baseline is what tells you.

Documentation

Open each workflow and write down, in plain words, what triggers it, which services it reads from and writes to, and what the happy path does. One paragraph per workflow is enough. Note anything surprising, especially workflows nobody knew existed (you will find some) and hardcoded values such as email addresses and spreadsheet IDs buried in the middle of the logic.

You are building the map that makes the next step safe, and that ends your dependence on the contents of one unavailable person's head.

Stabilize, then improve

Fix whatever is bleeding: the broken run, the expired credential, the failing integration. Smallest possible change, checked against the baseline. Resist bundling improvements into the stabilization. "While we're in here" is how a one-day fix becomes a three-week outage. Once the system has run clean for a week or two, then add the retries, the error handling, the redesign it probably deserves.

The rebuilder

When the second freelancer or agency arrives, watch for this: they look at the existing build for ten minutes and declare it garbage that must be rebuilt from scratch, this week, on their preferred stack. Sometimes a rebuild is the right call, and when it is we say so in the diagnostic, because the test for fixing or rebuilding a broken system is whether anyone can name the broken foundation. But a professional earns that conclusion by understanding what exists first, and can tell you specifically what is wrong with the current design and why repairing it costs more than replacing it. "I don't work with this tool" is a preference. A rebuild pitch on day one, before the access question is even settled, is a sales pitch, and it turns a medium problem into a large invoice plus weeks of downtime.

Two rules for the next build

Hiring a freelancer was fine, and the choice between a freelancer, an agency and an in-house hire turns on who is still there in six months rather than on skill. Two rules were missing. Every account, key, and workflow lives in accounts you own from day one, with the builder invited in as a user. And documentation is a paid deliverable, so the build is not finished until a stranger could operate the system from the docs. Both sit on the handover checklist we run at the end of every build. Put them into the contract before the next project starts, and a vanishing builder becomes an inconvenience.

One caveat. If the system is small, a single Zapier zap or a two-node flow, skip the visibility and documentation steps and rebuild it in your own account this afternoon; the order above is for systems big enough that you cannot hold them in your head.

If you would rather have the takeover done by people who do it routinely, we offer a written diagnostic for $500. Within 3 business days you get a map of what exists, what state it is in, which access is missing, and a fixed quote to stabilize it, with the $500 credited against the work. Most takeovers land between $1,500 and $4,000 and take 1 to 2 weeks. Start at our rescue service or tell us what you are dealing with.