Who owns the code of your software? What happens if your vendor disappears

Almost nobody asks who owns the code of their software until they need it. It's taken for granted: if you paid for it, it's yours. Then the day comes when the vendor shuts down, raises prices, stops answering or you simply want to switch teams, and the surprise shows up: the code is in their account, the servers are in their name and the contract says nothing about who owns the software. This article is about avoiding that surprise when you commission custom software, and about what to check if you already have it.

Paying for development doesn't make you the owner of the code

Software is protected the same way a book or a song is, and in general the rights to the code start with whoever writes it. When you hire an outside company to build custom software, what becomes yours is what the contract assigns to you in writing. If it says nothing, you may end up with little more than permission to use it, which is not the same as being able to modify it, have another team work on it or sell it along with your business.

This isn't legal advice, and if you're about to sign something important, have your lawyer review it. But it's enough to know what to ask for: a written assignment of the rights to the code, spelled out in full (use, modify, adapt and exploit it commercially), with no time limit and valid worldwide. If the vendor pushes back on that, you've already learned something important about the relationship.

What nobody owns exclusively

No software is written entirely from scratch. Every application uses open-source libraries and third-party services, and that's a good thing: there's no point paying to reinvent what's already solved. Those pieces aren't yours or your vendor's: they're used under their own licenses. The sensible thing is to know which ones they are and that their licenses allow the commercial use you're going to make of them.

The delicate case is a different one: companies that build your product on top of a base of their own that they reuse with every client. That isn't bad in itself, but they won't assign that part to you, because it also belongs to others. Ask which parts are theirs and under what license you use them. The good answer is a perpetual, irrevocable license that doesn't depend on you continuing to pay them. The bad answer is finding out, as you leave, that your application doesn't work without a piece that stayed behind with them.

The code is only one part of what has to be in your name

Having the code files in a zip doesn't help much if everything else lives in someone else's accounts. Real ownership of your software is split across several pieces, and all of them should be in your name:

The repository, which is where the source code lives with its full change history, in an account belonging to your company and not to the vendor. The cloud, meaning the servers and the database, with the subscription and the bill in your name. The domain and its configuration. The accounts for the services the application uses: the payment gateway, email delivery, the app stores. Admin access to all of the above. And the backups, stored somewhere you can reach without asking anyone for permission.

With that, your data is truly yours. Without it, the code can be yours on paper while your business still depends on someone else opening the door.

What happens if your vendor disappears

If everything above is in your name, a vendor disappearing is a problem, but a solvable one: you hire another team, give them access and they pick up where the previous one left off. It will take them a while to get up to speed, and how long depends on how well documented the project is, but you don't have to start from zero.

If it isn't, the conversation changes completely. You have to negotiate the handover of the code, the data and the domain with someone who no longer has any interest in helping you, or who simply no longer exists. In the worst case, the only way out is to rebuild the application from the outside, which means paying for the project twice. We explain this in more detail in cheap development, expensive maintenance: in part of the industry, leaving being more expensive than staying is not an accident, it's the business model.

Owning the code isn't enough if nobody understands it

There's a second, subtler way to get trapped: the code is yours, but the knowledge isn't. Nobody knows why it was built that way, how it gets deployed or what breaks if you touch a piece, and every question sends you back to the original vendor. Owning the code solves the legal problem; documentation solves the practical one.

That's why we deliver every project with full documentation and an AI that knows your product, built on that documentation and running in your own subscription. A new team can ask it how something works without depending on us, which is exactly the point.

Five ownership questions to ask before you sign

Which account will the repository live in, and from when: from day one or at the end? Whose name will the cloud, the domain and the third-party services be in? What does the contract say about assigning the rights to the code: modifying it, exploiting it, for how long and where? Which parts are not yours, and under what license will you use them? And if the relationship ends tomorrow, what exactly do they hand over?

They're only uncomfortable questions for someone with something to hide. A good vendor answers them in the first meeting without beating around the bush, and they usually go hand in hand with the ones we cover in how to choose a development team without being technical.

How we do it

The code, the repository and the infrastructure are in your name from day one, not when the project ends: you own your software while it's being built, not afterwards. The cloud too: you pay for usage directly to Microsoft, without going through us and with no markup, so you see the same bill we would. If tomorrow you want to continue with another team, you give them access and they carry on.

We don't do it out of generosity: it's the way of working we think is honest, and the one we chose precisely because we've been on the other side. Our exit plan starts on day one, and that's how we approach any custom software development. If you have a project underway and don't know who owns the code, or you want to start one knowing it from the outset, tell us about your case.