Who actually owns your automations?

What actually needs to be in your name?

Six things, and firms usually have two or three of them. The gaps tend to be invisible until the day they matter.

1. Accounts. The automation platform, the model provider, any hosting, the domain and DNS, and any new software the build required. Registered to a firm email address, paid on the firm's card, with a partner able to log in.
2. Credentials and API keys. Issued from your accounts, stored in your firm's password manager, and rotatable by you. A key issued from the provider's account is the single most common ownership gap.
3. Workflow definitions. The exported files that describe what each workflow does. Keep a copy somewhere you control, not only inside the platform.
4. Custom code. Any scripts or functions written for you, in a repository your firm owns, with the contract assigning the intellectual property to you on payment.
5. Documentation. What each workflow does, what triggers it, which systems it touches, how it behaves when it fails, roughly what it costs to run, and who to call.
6. Your data. Where it sits, how to export it, and how long it is kept.

Note what is not on that list: the provider's skill, their templates, their general methods. Nobody reasonable expects to own those. The line sits at the thing built for you and the accounts it runs in.

Why does building in your own accounts matter?

Three reasons, and only one of them is about trust.

Continuity. Automations sit in the middle of intake, invoicing and reporting. If a workflow stops because a relationship ended or a contractor changed careers, the work does not pause politely. Anything that runs your cashflow should survive the loss of any single supplier, and accounts in your own name are what make that true.

Price discipline. When the build lives in your accounts, you can get a second quote for the next change. When it lives in someone else's platform, you cannot, and both parties know it.

Answering questions about data. Firms that answer to clients, insurers and regulators are periodically asked where client information is processed and who can access it. That question is straightforward when the accounts are yours: you can see the settings, the region, the access list and the spend. It is much harder when the honest answer starts with the phrase our provider handles that.

What does lock-in actually look like?

It rarely announces itself. These are the patterns worth recognising before you sign anything.

• The proprietary wrapper. The build runs on the provider's own platform rather than a tool you could hold an account with. It works well, right up until you leave, at which point it does not come with you.
• Their key, your workflow. The automation calls a model using the provider's API key, with the usage rebilled to you. You cannot see the real spend and you cannot keep running it without them.
• Guest access to your own build. The platform account is under the provider's email and you have been added as a collaborator. That is not your account, whatever the invite says.
• The domain held elsewhere. Common in web work. The domain sits in an agency's registrar account, and untangling it later can affect your email as well as your site.
• No export, no documentation. Ask for the workflow file and the answer is that they manage that internally. That is a policy, not a technical limitation.
• A monthly fee that is really a licence. Ongoing support is a legitimate product. A monthly fee you must keep paying to continue using something you already paid to have built is a different thing, and the paperwork should say which one it is.

None of these make a provider dishonest. Some are ordinary business models, and hosted arrangements genuinely suit some firms. The problem is only ever the version you did not realise you were buying.

What should you ask any provider?

Ask these before the work starts, in writing. A good provider will answer all seven without hesitating.

1. Whose name is on each account this will run in, and whose card pays for it?
2. Whose API key does the workflow use, and can I see the usage myself?
3. Can I export the workflow definition today? Can you show me the file?
4. Who owns any custom code written for us, and at what point does that transfer?
5. On the day we stop working together, what keeps running and what stops?
6. What documentation do we get at handover? Can I see a redacted example from another client?
7. Is the ongoing fee support, or is it a licence to keep using what we paid you to build?

Question five is the one that separates providers. The answer either includes the word everything, or it does not.

Contract terms are worth having reviewed by someone engaged to advise your practice, particularly the intellectual property assignment and the termination clause. That is not an expensive review and it is the right place to spend a small amount of legal budget.

What does a clean handover contain?

A handover is complete when you could sack the provider that afternoon and lose nothing but their help. Work through it as a checklist, and actually perform each step rather than accepting that it has been done.

• You log in to every account yourself, from your own device, using credentials in your password manager.
• You rotate one API key while the provider is still available, to prove you can.
• You hold exported copies of every workflow file, stored somewhere outside the platform.
• Any custom code sits in a repository your firm owns, with the licence or assignment recorded.
• You have a one-page map per workflow: trigger, steps, systems touched, what happens when it fails, and roughly what it costs a month.
• You have a short recorded walkthrough. A ten-minute screen recording is worth more than thirty pages of manual.
• The fix window and what follows it are written down, including what support costs and whether it is optional.

If a provider builds this way from day one, handover is a formality rather than an event. That is the tell for how they have set the work up.

What if you are already locked in?

Start by finding out how bad it is, calmly, before you have any conversation about it. Make a list of every account the automation touches and mark each one as yours, theirs, or unclear. Try exporting one workflow. Check who the domain is registered to.

Then ask, politely and in writing, for the things that are missing. Many providers will simply hand them over, because the arrangement grew out of convenience rather than strategy. If the answer is a refusal, you now know what you are dealing with and can plan a rebuild at a time you choose rather than one forced on you. A rebuild you saw coming is a manageable project. One that arrives on a Friday afternoon is not.

What to do next

Run the ten-minute test on whatever you already have. Log in, export, rotate. Write down what you could not do without asking someone else, because that list is your actual exposure.

For anything you build next, settle the account and key question before the scope conversation, not after. It is the cheapest clause to agree at the start and the most expensive one to retrofit. Shift builds in the client's own accounts from day one for exactly this reason, and the honest reason it is worth insisting on with anyone you hire is that it makes leaving easy, which is the only thing that keeps a supplier sharp.