Here's something we see all the time: a business owner calls us in a panic because they just realized they don't actually own the software they paid to have built.
Maybe their agency went dark. Maybe they asked for the source code and got a vague excuse. Maybe they tried to hire a new developer and were told the codebase is locked inside a platform they can't export from.
It happens more than you'd think. And by the time most people realize the problem, they've already spent tens of thousands of dollars on something they can't control.
This post is about how to avoid that situation. We've spent years rescuing projects from exactly these scenarios, so this isn't abstract advice. It's what we've learned from cleaning up the mess.
What "Code Ownership" Actually Means
Code ownership is simple in concept: whoever owns the code has the legal right to use, modify, distribute, and host it. They control the repository where it's stored. They decide who gets access.
But here's where it gets tricky. A lot of business owners assume that because they paid for the software, they own it. That's not always true.
The default under U.S. copyright law is that the person (or company) who writes the code owns the copyright, unless there's a written agreement that says otherwise. So if your contract with a development agency doesn't have a clear intellectual property assignment clause that transfers ownership to you, you might be paying for software that legally belongs to someone else.
We've seen this play out in ugly ways. A founder pays $80,000 for a custom application. Two years later, the relationship sours. The vendor refuses to hand over the repository. The founder's lawyer looks at the contract and finds... nothing about IP ownership. The vendor built it, so the vendor owns it.
That's a bad day.
Six Types of Vendor Lock-In (and How to Spot Them)
Vendor lock-in isn't always obvious. Sometimes it's buried in a contract clause. Sometimes it's a technical decision that seems harmless at the start. Here are the patterns we see most often.
1. Hosting Lock-In
Your application only runs on the vendor's servers. They control deployment, uptime, and access. If you leave, you can't take your app with you because it's configured to run only in their environment. Some vendors charge monthly "hosting fees" that are really just rent for access to your own software.
2. Knowledge Lock-In
There's no documentation. No architecture diagrams. No comments in the code. Everything the vendor knows about how your system works lives inside their heads. If they leave, or if you fire them, that knowledge walks out the door. A new developer coming in would essentially need to reverse-engineer the entire system.
3. Platform Lock-In
Your software was built on a proprietary platform like Bubble, OutSystems, or a similar low-code tool. These platforms are great for prototyping, but the "code" they produce can't be exported. You don't own source code. You own a configuration inside someone else's system. If the platform changes pricing, shuts down, or removes a feature you depend on, you're stuck.
4. Contractual Lock-In
The contract has IP clauses that favor the vendor. Maybe they retain ownership of "reusable components." Maybe they have a license-back arrangement that lets you use the software but not modify it without their involvement. These terms are sometimes buried in boilerplate that nobody reads carefully enough.
5. Technical Lock-In
The vendor used their own proprietary framework, libraries, or tools that only they understand and maintain. Your codebase has dependencies on packages that aren't open-source, aren't documented, and can't be replaced without a major rewrite. You're not locked into a vendor by contract; you're locked in because nobody else can work on the code.
6. Data Lock-In
You can't export your own data. Or you can export it, but only in a format that's useless without the vendor's tools. Your customer records, transaction history, operational data... all sitting in a system you can't get it out of in any practical way.
Most businesses we've helped were dealing with at least two of these at the same time. The patterns compound. A vendor who won't give you the code is also unlikely to give you documentation or a clean data export.
Sound familiar? Book a free discovery session and we'll help you figure out where you stand.
The Real Cost of Being Locked In
The financial cost is the obvious one. You're paying above-market rates because you can't switch vendors. You're stuck with whoever built it, at whatever price they set, because switching means starting from scratch.
But the less obvious costs are worse.
Speed. When you're locked to a single vendor, everything moves at their pace. Need a feature by next month? Get in line. Their other clients need things too. You can't hire a second team to help because nobody else can touch the code.
Quality. A vendor who knows you can't leave has less incentive to do great work. We've taken over codebases where the quality declined sharply after the first year, once the vendor realized the client was effectively captive.
Risk. What happens if your vendor goes out of business? What if their lead developer quits? What if they get acquired and your project isn't a priority for the new owners? If you don't own the code and can't access the servers, you're one bad event away from losing your entire technology investment.
We worked with a mid-size company that had been paying their original developer $4,000 a month in hosting fees for three years. The application ran on the developer's personal AWS account. When the business owner asked to move it, the developer quoted $25,000 for the "migration." The owner called us instead. We rebuilt the deployment on infrastructure the owner controlled in under two weeks.
That's $144,000 in hosting fees for software the owner thought they already owned.
Seven Questions to Ask Before You Sign Anything
If you're about to hire a development agency or freelancer, ask these questions before you sign a contract. The answers will tell you whether you're walking into a partnership or a trap.
1. Who owns the source code during and after the project?
The right answer is: you do. From day one. Not "after final payment" or "after a 12-month retention period." You own it now.
2. Where is the code stored? Can I access it anytime?
It should be in a repository you control, or at minimum one you have full access to. If the vendor says "we'll transfer it when the project is complete," that's a yellow flag. What if the project never completes?
3. What technology stack are you using? Is it open-source?
Open-source frameworks (React, Angular, Python, Node.js, Grails, .NET) mean any qualified developer can work on your code. Proprietary or heavily customized frameworks mean only that vendor can.
4. Can I hire another developer to work on this codebase?
This is the acid test. If the answer is anything other than an enthusiastic yes, dig deeper.
5. What happens if we end the relationship?
You should get full access to all code, documentation, environments, and data. No exit fees. No hostage negotiations. A good vendor will have a clear offboarding process because they've thought about this ahead of time.
6. Will you provide documentation?
Code without documentation is a ticking time bomb. You need architecture docs, deployment instructions, and enough context that a new team could pick it up without calling the original developers.
7. Can I export all my data?
In standard formats. Not a proprietary dump. Your data belongs to you and you should be able to get it out at any time, in a format another system can use.
If a vendor gets defensive about any of these questions, that tells you everything you need to know.
How We Handle Code Ownership at Zelifcam
We think this stuff matters, so here's how we do it. No hedging.
You own 100% of your code. We write it. You own it. Full stop. There's no "license back" arrangement, no retained IP on components, no surprises.
Your code lives in your repository. We either work directly in a repo you control, or we transfer everything to you. You have access from day one, not "when the project wraps up."
We use standard, open-source technology. Our stack is built on proven frameworks like Grails, Python, React, and .NET. Any competent developer can read, maintain, and extend the code we write. We don't use proprietary tools that create dependency on us.
We write documentation. Because we believe a good partner makes themselves replaceable. If you ever need to bring in a different team, they should be able to get up to speed from our docs. That's a feature, not a bug.
We'll tell you when you don't need custom software. Sometimes the honest answer is "use an off-the-shelf tool." We'd rather give you good advice and earn your trust than sell you a project you don't need.
Transparency and ownership aren't just nice words for us. They're how we run every engagement. You can read more about who we are and how our discovery process works.
What to Do If You're Already Locked In
If you're reading this and realizing you might already be in a bad situation, here's a practical starting point.
Read your contract. Look for sections on intellectual property, code ownership, and termination. If you don't have a contract (it happens), that's actually a bigger problem.
Try to access your code. Log into the repository. If you don't have credentials, ask for them. How your vendor responds will tell you a lot.
Get a second opinion. Have another developer look at your codebase and your hosting setup. They can tell you quickly whether you're dealing with standard technology or something proprietary.
Start planning your exit. Even if you stay with your current vendor, you should have a plan for what happens if the relationship ends. That means having copies of your code, your data, and your documentation.
We've helped dozens of businesses through this process. Sometimes it's straightforward. Sometimes it requires a full software rescue. But the first step is always the same: figure out what you actually own.
Not Sure Where You Stand?
If you're wondering whether your code, data, or hosting is really yours, let's talk. We'll review your situation and give you honest, practical advice on your options.