There is a version of this conversation that happens three years too late. The system works, the relationship has cooled, and somebody asks for the source code. What comes back is a sentence about a licence, and the company discovers that the thing it paid to have built was in fact rented.
That outcome is not usually anybody being dishonest. It is a question nobody asked at the start, answered by default in the supplier's favour.
Ownership is not one thing
"We own it" is too coarse to be useful. Five separate things can sit in different hands, and a contract that only mentions the first is not saying much.
The source code. The text of the programme written for you.
The intellectual property in it. Copyright transfers by agreement, in writing. In Romania, a development contract that is silent on this does not automatically move the economic rights to the client, so silence is not neutral. It is a position.
The database. Both the schema and the data. This one is occasionally overlooked and it is the one that hurts most, because a system you can host but cannot query is only half yours.
The infrastructure. Whose account is the server in. Whose name is the domain in. Who holds the DNS.
The third-party components underneath. Every real system uses libraries somebody else wrote. What matters is that they are under permissive licences you can keep using indefinitely, and not a commercial component licensed to your supplier rather than to you.
That last one is the quiet failure. A system can be entirely yours, with a component in the middle that stops working when your supplier's licence lapses.
The questions worth asking, before signing
Read them out loud on the call. The hesitation is the answer.
- On the day I make the final payment, do the economic rights in the source code transfer to me, in writing?
- Do I get the source code, including the deployment configuration, or only the running system?
- Is the database schema mine, and can I get a full dump on request without asking permission?
- Whose accounts hold the server, the domain and the DNS? If they are yours, what does the transfer to me look like?
- Are there any components with a licence that is not permanent and unrestricted? Name them.
- If we part ways tomorrow, what exactly do I have?
A supplier who has done this before answers all six without checking. One who has not will need to come back to you, which is fine, but note that you have just asked them to decide something they had not decided.
What a real handover contains
Ownership on paper and ownership in practice are different. We have seen companies with excellent contracts and no ability to do anything, because what they received was a zip file.
A handover that actually works:
The repository, with its history. History is not sentiment. It is the record of why things are the way they are, and it is the difference between the next developer understanding the system in a week or three months.
A README that a stranger can follow. How to run it locally, how to deploy it, what environment variables exist and what they do. The test is literal: give it to a developer who has never seen the project and watch them get it running without asking a question.
The database schema and a restore procedure, tested. Not "here is a dump", but a documented path from empty machine to running system.
Credentials and accounts, transferred rather than shared. Ownership of an account is not a copy of a password.
Written documentation of the decisions, particularly the odd ones. Every system has three or four places where the obvious approach was not taken. Undocumented, each of those is a trap for whoever comes next, who will "fix" it and break something.
A named list of third-party components and their licences.
What we do, and why we say it in public
The source we write for you, the database, and the intellectual property in them transfer to you on final payment. The infrastructure runs in your accounts from the start rather than being migrated at the end. The standard components underneath come with permanent, unrestricted licences. There is no per-seat fee and there is no mechanism by which we can hold the work hostage, which is deliberate: a supplier who can hold work hostage will eventually be in a negotiation where somebody suggests it.
We publish this because it is checkable, and because the alternative is asking you to take it on trust in a market where the default is worse.
The uncomfortable corollary
If the code is genuinely yours, your supplier has no lock-in, which means they have to be worth keeping on merit. That is the right incentive and most suppliers do not love it.
It also means you can be left. A supplier who cannot trap you can also walk away, and the protection against that is not a contract clause. It is that the system is documented, runs on mainstream technology, and can be picked up by any competent developer in the country. Which is a question worth asking separately, because it changes what you should be buying: not the cheapest build, but the one somebody else could take over.