Who owns the code in your custom software — and how to avoid lock-in

“Is the code ours, or the vendor’s?” is a question most SMEs ask too late — usually when they want to switch providers or bring in a second team to extend their custom software, and discover they can’t. At Evicron, an AI and custom software studio based in Barcelona founded in 2019 with 200+ projects delivered across 12 industries, it’s a clause we review with every client before signing, because the default answer — in Spain and in most jurisdictions — doesn’t favour whoever paid for the development.

The default rule: the developer owns the code, not the client

Legal guidance on software contracts is consistent on this point: unless the contract says so explicitly, the developer keeps the intellectual property rights over what they build, even if the client paid for it (dig.es). Paying the invoice doesn’t transfer ownership — you need an assignment clause that states exactly what is transferred, for how long, in which territory, and which rights are included (reproduction, distribution, modification, public communication). Without it, a client can use the software they paid for, but may not be entitled to modify it, resell it, or hand it to another vendor for maintenance.

Assignment and licensing are not the same thing

A common nuance: the vendor may want to keep ownership of reusable frameworks or components built across several projects, assigning only what’s specific to your application. In that case, the contract needs to clearly separate what is assigned from what is merely licensed — a distinction that matters a lot if you’re later raising investment or going through technical due diligence, since an investor will want to know whether the code genuinely belongs to the company or depends on a third-party licence.

What the contract needs to guarantee so you don’t get stuck

Vendor lock-in rarely shows up all at once — it builds up every time one of these guarantees is missing from the contract.

• Delivery of the full source code, not just the compiled executable. This is flagged as the most common failure: a client who only receives the running program can’t maintain or extend it with another team, even if they technically “own” it on paper.
• Technical documentation and repository access from day one, not only at project close, so any developer can pick up the project without relying on the original vendor still being around.
• Database schemas and credentials for connected services, so migration doesn’t mean starting from zero.
• An escrow clause, especially useful with smaller vendors: a neutral third party holds the code and releases it to the client if the vendor shuts down or stops supporting it.
• Data portability and open formats wherever possible, so exporting your own data doesn’t depend on a paid migration service from the same vendor (contracko.com).
• A clear exit clause: what the vendor hands over, within what timeframe, and with what support if the relationship ends. It’s the part almost nobody negotiates when signing, and the one that costs the most to sort out afterwards.

Signs you already have lock-in with your current vendor

You don’t need to want to switch providers to spot it. Common signs: only the vendor has access to the server or repository; even a small change has to go through them; data sits in a proprietary format that doesn’t export to an open standard (CSV, JSON, standard SQL); or the contract auto-renews with such a short notice period that there’s never real time to evaluate alternatives. None of these signs are illegal or unusual on their own, but if several show up together, the vendor — not the company — holds the leverage at the next renewal.

Some degree of dependency can be a reasonable trade-off — for example, in exchange for stronger support guarantees — as long as it’s a conscious choice, not the result of never asking at signing time.

How we handle it at Evicron

We work in 4 phases with weekly sprints, with a clickable demo already by week two, so the client sees working code from the start rather than only at the end of the project. The one condition we keep across every project is the same one legal guides recommend: the client owns the code, with no lock-in. If they ever want to switch teams, they take the full repository, documentation, and credentials with them — without depending on us staying on as the maintainers.

If you’re evaluating custom software for your company and want to know what to ask before signing — or want a second look at a contract already on the table — get in touch and we’ll go through it together in a first, no-cost conversation. You may also find our guide on how much custom software development costs useful, since it covers the question that almost always comes right after this one.