Free self-check · no signup
For freelancers and small agencies who build n8n workflows for clients. Work through it against the last project you handed over — not the one you wish you had handed over.
This is a checklist, not advice about your contract, your taxes or your legal obligations. It does not promise your automations will stop failing — it only helps you see, before your client does, which parts of the handover were never actually agreed.
Who actually holds the keys.
What it looks like: the workflows run on a VPS, a Docker host or an n8n Cloud account, and nowhere in writing does it say who pays for it, who is the admin, and who can restore it if the box dies.
Why it costs you: the day the client wants to move on, or the day the host suspends the account, you become the single point of failure for infrastructure you were never paid to operate.
The fix: one line in the handover document — instance type, who pays, who is admin, who is the backup admin.
What it looks like: the Google, Slack, Airtable or CRM credentials inside n8n were created with your own OAuth login, or with an API key generated from your seat.
Why it costs you: every credential expiry, every re-auth, every token rotation comes back to you forever — usually unpaid, usually urgent.
The fix: create credentials from a client-owned service account wherever the vendor allows it, and list every credential with the account it belongs to.
What it looks like: you signed up for the LLM API key, the scraping API, the SMS provider or the paid tier that keeps the workflow inside its rate limits.
Why it costs you: you are financing and legally holding accounts for someone else's business, and the workflow silently breaks the month you cancel.
The fix: an account list with owner, plan tier, renewal date and the rate limits that matter.
Can the client see what they own.
What it looks like: the client has access to n8n and sees a list of workflow names. That is the entire documentation.
Why it costs you: they cannot tell what is live, what was an experiment, and what is safe to disable — so they ask you, every time.
The fix: one row per workflow: name, purpose in plain language, status (live / paused / experiment), owner, last changed.
What it looks like: nobody has written down what starts each workflow — a webhook, a cron, a poll every 5 minutes, a manual run — or how often it fires.
Why it costs you: "why did this run twice?" and "why didn't this run at all?" become your problem to investigate for free.
The fix: a table of trigger type, frequency, and what the expected volume looks like on a normal day.
What it looks like: the workflow writes to a sheet, a database, a CRM field or a storage bucket, and only you know which one, and in what shape.
Why it costs you: the client's next developer changes a column, the workflow breaks, and you get called.
The fix: for each workflow, name the destination systems and the fields written.
What happens when it breaks at 2 a.m.
What it looks like: failures appear in the executions list and nowhere else. Or the error notification goes to your inbox only.
Why it costs you: you are the client's monitoring system, unpaid, indefinitely.
The fix: an error workflow attached to every production workflow, sending to a channel the client can also see.
What it looks like: nobody decided what should happen when a step fails halfway — retry how many times, is a re-run safe, will the customer get two emails or an invoice twice.
Why it costs you: the failure mode is discovered in production, on real customer data, and the conversation that follows is not a pleasant one.
The fix: for each workflow, one line: retries, and whether re-running is safe or creates duplicates.
What it looks like: the informal answer to "who do we call at 2 a.m." is "message you on WhatsApp".
Why it costs you: availability you never priced, never scoped and cannot refuse without looking unhelpful.
The fix: written response expectations — what counts as urgent, what your hours are, what is billable, and what the client can do themselves first.
Is the project actually finished.
What it looks like: the project ends when the client stops asking for changes, not when an agreed list of criteria is met.
Why it costs you: scope keeps expanding, and the final invoice keeps moving away.
The fix: acceptance criteria written before build, signed off in one message after demonstration.
What it looks like: you demonstrated it once on a screen share, using data only you know how to produce.
Why it costs you: every future doubt about whether it is working becomes a support request instead of a two-minute check they run themselves.
The fix: a short test procedure with safe sample input and the expected result, that a non-technical person can follow.
What it looks like: nobody has written down what happens when you leave — which of your accesses get revoked, which exports get handed over, what the client keeps.
Why it costs you: you stay logged into a client's systems for years after the money stopped, which is a risk you carry for free.
The fix: an offboarding list — workflow JSON exports handed over, credentials transferred, your access removed on a named date, confirmed by both sides.
Count the gaps where your honest answer was no, that is not written down anywhere.
| Gaps open | What it usually means |
|---|---|
| 0–2 | Your handover is in good shape. The remaining gaps are worth closing before your next project. |
| 3–6 | Normal for a working freelancer. The open gaps are where unpaid support hours tend to accumulate. |
| 7–12 | Your projects likely never fully close. Each finished client keeps a permanent claim on your attention. |
Whatever your number is, the pattern matters more than the score: gaps cluster. If Part A is open, Part D is almost always open too — you cannot offboard cleanly from accounts you still personally own.
Pick the single gap that cost you the most time in the last three months and close it for your next project only. Do not retrofit every past client at once; that is a week of work with no invoice attached.
Disagree with one of the twelve? That is the most useful thing you could tell me. I am collecting how people actually handle handover in practice, and the gaps people think are wrong are the ones I learn most from.
khangpanda@pandify.io — one line is enough. No list, no newsletter, no follow-up sequence.