Who owns the system when it is built for you
Ownership has five parts and vendors answer confidently about one of them. Accounts, credentials, code, data, and knowledge. You can own the code entirely and still be completely dependent — if it runs on their accounts, with their keys, and nobody on your side understands it.
Written by Josh Soderblom, founder of ikonic303.
Ask all five before you sign. Afterwards, every one of them is a negotiation you will lose.
1. Accounts
Whose name is on the subscriptions the system depends on?
The common pattern: an agency builds on their platform account, under their agency licence, sometimes at a rate you cannot get directly. It works well and costs less — until you want to leave, at which point the system does not travel and you are rebuilding from scratch.
What good looks like: every account in your company's name, billed to your card, with you as owner and them as a user you can remove.
2. Credentials
Who holds the API keys, and can you see them?
Even with accounts in your name, a system built with keys only the vendor has is a dependency. When they stop answering, nothing can be changed and nobody can even see what is connected to what.
What good looks like: every credential in your password manager, documented, with what it is for written next to it.
3. Code and configuration
Where does it live, and can you get at it without asking?
“You own the IP” is a contractual statement that means little if the code is in the vendor’s repository and the configuration exists only in a UI you cannot log into.
What good looks like: code in a repository your company controls. Configuration exported or documented. You could hand it to another firm tomorrow.
4. Data
Can you get it all out, in a usable format, without asking?
The one people check, and still the one that catches them — because “we can export” often means a CSV of the main table and none of the relationships, history, or attachments.
What good looks like: a full export you have actually run once, during the engagement, and looked at. Not a promise. A file.
5. Knowledge — the one that actually matters
Does anyone on your side understand how it works?
You can own all four of the above and still be stuck, because the only person who knows why it does that thing on the fifteenth of the month has left.
What good looks like: documentation written as it was built. At least two of your people trained. A written statement of what will break it and what to do.
The test question
“If you stopped answering the phone tomorrow, what happens to this system?”
The honest answers are:
- “It keeps running. You’d need someone technical for changes.” — good.
- “It runs, but you couldn’t change it.” — acceptable, if you know that and priced it in.
- “It stops.” — you are renting your operations. That may still be a fine deal, but you should know you are doing it.
Ask it in the sales conversation. The response tells you a great deal, and how comfortable they are with the question tells you more than the answer.
The reasonable version of vendor lock-in
Not all dependency is predatory. A vendor who hosts and maintains something is providing real value and charging for it. Software you buy is a dependency and nobody objects.
The problem is undisclosed dependency: buying what you believe is an asset and discovering at renewal that it is a rental. That discovery always happens at the worst moment, because that is when you check.
So ask the five questions early, write the answers into the agreement, and price the deal you are actually getting.
What we build, and the rule underneath it → · Twelve questions before you sign →
Twelve questions before you sign · Build or buy an internal tool · What we build
Get in touch
Email solutions@ikonic303.dev to start with the measurement. ikonic303 is based in Colorado and works with clients nationwide.