When you pay someone to build an automation, it's easy to assume you own the result. Often you don't. Ownership is the single most important thing to nail down before you sign, because it decides whether you're buying an asset or renting one indefinitely.
Two ways it quietly goes wrong
The first is account lock-in: the workflow runs in the agency's Make or n8n account, on their API keys, under their login. It works beautifully, until you stop paying, at which point it vanishes and takes your process with it.
The second is knowledge lock-in: even if it is technically in your account, there's no documentation, no explanation of how it works, and nobody on your team who could change a rule. You own the file but not the ability to run it.
What real ownership means
Ownership means three things together: the automation runs in your accounts and tools; you have documentation your team can read and edit; and you can change, extend, or switch it off without calling anyone. Anything less and you're dependent by design.
Questions that reveal the truth
Ask directly: whose accounts does this run in? Whose API keys? If we part ways, what do we keep, and can we keep it running? Will we get documentation, and will you walk our team through it? The answers separate partners who build you capability from vendors who build you a dependency.
How we handle it
Everything we build runs in your accounts, with documentation your team can read and change, and we hand it over so you're never locked in. We'd rather earn the next project because the last one worked than because you can't leave.