How do I avoid vendor lock in when hiring someone to build AI automations?

Lock-in is almost never announced in a sales call. It accumulates quietly, one convenient default at a time, and every one of those defaults is faster for the builder on the day it is made. The way to catch it is to ask, before the work starts, whose name is on each of the three things a working automation actually needs: the account it runs in, the connections it uses, and the number or address customers reach it on.

Start with the account. If the automation platform, the cloud project, the model provider, and the database sit inside a workspace registered to the vendor, then the vendor is your landlord and stopping payment stops the system. The fastest tell is not the contract, it is the billing email. Ask who receives the invoice from the automation platform and from the model provider. If those invoices go to the vendor and reach you as a line on their retainer, the account is theirs no matter what the proposal says.

Then the credentials, the API keys and app authorizations that let your systems talk to each other. These are created by a person logging into your CRM, your email, your store, and clicking approve. If that person used the vendor's login or a shared address the vendor owns, then leaving means re-authorizing every connection from scratch, usually while something is broken. Ask for each credential to be created from an address inside your own domain, and for you to hold the recovery on it. If you handle patient or payment data, ask in writing which outside services touch that data on the way through, and treat a compliance badge on a website as marketing rather than as an answer.

Phone numbers are the one people forget until the worst possible moment. A voice agent answers on a real number that lives inside a telephony account, and that account belongs to whoever registered it. Moving a number later is not a settings change: it depends on the account it currently sits in cooperating, and on the business details on that account matching yours. It is much easier to buy the number under your own business at the start than to negotiate for it during a breakup. Ask which company will appear on the telephony account, and ask before launch, not after.

Ask where the build itself is stored and what format it is in. Workflow automation should be readable by a developer who has never met the person who wrote it. Ours runs on n8n, a common automation tool, and every workflow exports as plain JSON that another n8n developer can open, edit, and redeploy. If part of the work is custom code, ask which repository it lives in and whose organization owns that repository, and get it in writing that the code is yours outright rather than licensed to you for as long as you keep paying.

Now the part most buyers get wrong: an export is not the same as ownership, and the word covers very different things. Ask what is actually in the file. A workflow export usually contains the structure, the steps, and the logic, but it deliberately does not contain your secrets, so the credentials have to exist on the other side before the import will run. Execution history is usually separate again, and if a customer or a regulator ever asks what your system did last March, that history is the answer. For anything conversational, the export you want includes the prompts, the knowledge sources the assistant reads from, and the escalation rules, not just a transcript dump.

There is a simple way to test all of this without a lawyer. Ask for a copy of the export today, in the middle of the project, rather than at handover. A vendor who builds in your account can send it in a few minutes because it is your file already. A vendor who has to schedule it, prepare it, or explain why it will be available at the end is telling you where the build really lives. Do the same with documentation: ask to see the written explanation of how one finished workflow works, and read whether a competent stranger could maintain it.

Every question above collapses into one, and it is the only question you have to remember: if I revoke your access and stop paying you this afternoon, what stops working? Ask it in the first call, ask it plainly, and listen to the shape of the answer rather than its length. The client-owned answer is short and boring: nothing stops, the workflows keep running, the logs keep writing, and your next developer opens the account and reads what is there.

Anything else is worth hearing out, because renting is not fraud, but it should be priced and understood as renting. The answers that should slow you down are the ones that describe a process instead of a state: a migration project, an export request, a wind-down period, a transition fee, or a promise that they would of course help you move. Help is not ownership. Help is a favor that depends on the relationship being friendly on the day it ends, which is the one day you cannot count on that.

Push one level further and ask them to name the last client who left and what that offboarding actually took. A vendor who has done it cleanly can walk you through the steps in under a minute. Ask what happens to your data if they go out of business, since a small agency going quiet is a more common ending than a dispute. And ask for their own numbers with a basis attached, measured or client-reported, because a vendor who labels the difference between a result and a projection is usually the same vendor who tells you the truth about who owns the account.

Ownership is a cost, and pretending otherwise would be its own kind of sales pitch. Buying the build outright means paying more up front than a low setup fee and a monthly retainer, and it means somebody on your side has to hold logins and remember they exist. There are cases where that is the wrong trade, and here is the honest version.

If what you need is one trigger and one action at low volume, a self-serve tool you configure yourself in an afternoon is cheaper than any agency, ours included, and portability barely matters because rebuilding it costs an afternoon too. If the automation is a ninety-day experiment you fully expect to throw away, rent it. Lock-in only bills you at the exit, and an experiment you plan to end anyway never really pays that bill.

The bigger case for not buying is that the process underneath is broken. Owning a bad automation is still owning a bad automation, and automating a step that should be deleted just makes the wrong thing happen faster and more reliably. If the work you are about to automate exists because two systems were never connected, or because a form asks for data nobody reads, the cheaper answer is to fix or remove the step and automate what survives. That is the finding a diagnosis is supposed to produce, and it is a good outcome even though it sells nothing.

Every good answer in this article costs nothing to write down, which is exactly why you should insist on it. Six lines cover it: the platform and cloud accounts are registered to your business, each credential is created under an address in your domain, the phone numbers are bought on a telephony account in your name, the source code and workflow files are yours outright rather than licensed while you pay, written documentation is a deliverable and not a favor, and offboarding is a defined number of days with no exit fee.

Watch what happens when you ask. A builder who already works this way will treat those lines as a description of what they were going to do anyway. A builder who does not will start explaining why their setup is better for you, and the explanation is usually true in a narrow way: their account really is faster to start in, and their shared credentials really do save a week. The question is whether that week is worth the cost of never being able to leave without a rebuild.

One more thing to write down: name the person who holds the admin login on your side. Ownership that lives with a single employee who leaves is only slightly better than no ownership at all, and an automation nobody on your payroll can log into becomes the vendor's again by default, without either side ever deciding it.