Source Code Ownership in Custom Software: Contract Clauses to Check
Code, database, server access and documentation: what should belong to you in custom software, which clauses to put in the contract and what to check at handover.
When you agree a project with a software company, the topics on the table are usually predictable: screens, features, timeline and price. The question of source code ownership ("who keeps the code when the project is finished?") often only comes up when something goes wrong. The company closes, the relationship breaks down, or you want to continue with a different team. If all you have on that day is a working screen and an invoice, you may realise you never actually owned the system you have used for years.
In this article we explain what custom software source code ownership covers in practice, which contract clauses to look for, the warning signs in proposals, and how to switch software development companies safely. At the end you will find a checklist you can use at handover.
What does source code ownership mean in practice?
Saying "we own the source code" means more than having a folder full of files. To hand the software over to another team, change its server or add a new feature years later, you need several pieces in your hands at the same time.
Code
All of the software's source files, including the admin panel, complete and up to date. The healthiest setup is being able to access the code repository through an account in your own name. That way you hold not just the latest version but the full history of changes. Compressed, minified or deliberately obfuscated code should not count as "delivered code".
Database and data
Customer records, orders, stock movements, user accounts: this is your business. You should be able to take a full backup of the database, know the table structure (the schema) and export the data in a common format. The contract should state clearly that the data belongs to you and that it can never be held "hostage" under any circumstances.
Server, domain and accounts
You should be the registrant of the domain name. The hosting or cloud server account should, where possible, be opened in your name, with the developer given access only as an authorised user. The same rule applies to payment gateways, SMS, email delivery services, maps and similar third-party accounts. If these accounts were opened in the developer's name, you will have to take each one over individually when the relationship ends.
Documentation
Installation steps, server configuration, environment variables, how integrations work and, where relevant, API documentation. Good technical documentation lets another developer get the project running within a reasonable time. Receiving code without documentation is like buying a machine without a manual.
Third-party licences and open-source libraries
Almost no software is written entirely from scratch. Projects use open-source libraries, paid components, fonts or theme elements. You do not own these parts; you use them under their own licences. Some open-source licences can create specific obligations when you distribute the code. That is why it matters to ask for a list of the components used and their licences, and to find out whose name the paid licences are registered under.
The legal framework: general information on copyright and data protection
This section is general information to help you understand the topic, based on the Turkish framework we work within. Rules differ by country, so consult a lawyer about your own situation and jurisdiction.
Copyright: Turkey's Law on Intellectual and Artistic Works (FSEK)
In Türkiye, computer programs are protected as works under the Law on Intellectual and Artistic Works (FSEK). As a general rule, rights in a work arise with the person who creates it. When you commission software from an external company, the economic rights such as reproduction, adaptation and distribution only pass to you if this is done in writing and each right being assigned or licensed is listed individually. In other words, a general sentence such as "once paid, the software belongs to the client" may not give you the protection you expect. Many other countries also have specific rules on how software rights are transferred, so check what applies where you and your developer are based.
It helps to separate two concepts here. An assignment means the rights pass to you. A licence means the rights stay with the developer and you are given permission to use the software. The contract should state whether the licence is exclusive or non-exclusive, its duration, its territorial scope and whether you are allowed to modify the software. Decide which suits you together with your lawyer.
Data protection: Turkey's KVKK (and similar rules elsewhere)
If your software stores customer, employee or member information, data protection law applies. If you operate in Türkiye, that is the Personal Data Protection Law (KVKK); in the EU and UK the comparable framework is the GDPR, and other countries have their own rules. KVKK refers to two main roles. The data controller decides why and how personal data is processed; in most projects that is you. The data processor processes the data on the controller's behalf, based on the authority the controller gives; the company that hosts or maintains the software is usually in this position.
The roles should be clearly defined in the contract, along with the purpose and limits of the developer's access to the data, the security measures to be taken and the return and deletion of data when the relationship ends. Situations such as the server being located abroad can trigger additional rules that need separate assessment, so ask your lawyer about this too.
Software development contract clauses: 8 points to check
Treat the points below as a checklist, not a ready-made template. The legal wording is your lawyer's job. Your job is to make sure these topics are covered in the contract.
- Intellectual property assignment or licence. Which rights pass to you, when (for example, on final payment) and with what scope. If the developer has shared modules it built earlier and uses in other projects, what kind of usage right you are granted for those.
- Handover list. An annex listing everything to be delivered, item by item: code, database, documentation, access credentials and design files. "The project will be delivered" is not a handover list.
- Acceptance process. Which tests the software must pass before it counts as accepted, and how quickly bugs will be fixed.
- Maintenance and support. Whether support is provided after go-live, its scope, response times and cost. The contract should state clearly that ending maintenance does not affect ownership of the code and data.
- Confidentiality (NDA). That the business information, customer lists and pricing structure you share will be kept confidential, for how long, and the consequences of a breach.
- Data protection roles. Definitions of the data controller and data processor roles, security measures, and the return and deletion of data when the relationship ends.
- Third-party components. Whose name paid licences will be registered under and who pays renewal costs.
- Exit plan. If the relationship ends for any reason, what the developer will hand over and within what timeframe, how access will be transferred and how much support it will give during the transition.
Before contract talks begin, you should already know whether the project will use an off-the-shelf solution or custom development. If you are undecided, our comparisons such as quoting software: off-the-shelf vs custom and inventory management software: off-the-shelf vs custom are a good starting point for thinking it through.
Red flags in proposals
Vendor lock-in is the general name for situations that leave you dependent on a single company. Sometimes it is set up deliberately, sometimes it simply comes from carelessness. If you notice any of the signs below at proposal stage, ask for an explanation before signing.
| What you see in the proposal | Why is it risky? | What should you ask? |
|---|---|---|
| No mention of source code at all | If the contract is silent, the rights may stay with the developer | When and with what scope do the code and rights pass to us? |
| "Source code delivered for an additional fee" | You may have to buy the actual product separately | What does this fee cover, and can it be included in the price now? |
| Server and domain in the developer's name | If you want to leave, your website and email may be held hostage | Can the accounts be opened in our name with you given access? |
| Monthly rental model only | When you stop paying, the system shuts down too | If the contract ends, can we take the data and the code? |
| Technical documentation out of scope | Another team will struggle to take over the project | Which documents will be delivered, and is there a sample? |
| Access cut off if maintenance stops | Maintenance and ownership have been tied together | If we end maintenance, which access stays with us? |
| No data export option | You cannot move your data to another system | In what format and how quickly can we get our data? |
Price on its own can also be a signal. A quote far below the market may mean the cost will be recovered later through licence, rental or compulsory maintenance fees. If you want to know what drives the price, we break down the cost items one by one in our article on custom software development cost.
Software handover documents: a checklist
When the project goes live, or when you part ways with a developer, you can print the table below and tick it off line by line. Before marking any item as "received", test that you can actually access it.
| Handover item | How to verify it | Status |
|---|---|---|
| Complete source code (including admin panel) | See the latest version in the repository under your own account | ☐ |
| Code change history | Check that past commits are present in the repository | ☐ |
| Full database backup and schema | Take the backup file and ask for the list of tables | ☐ |
| Domain registrant ownership | Confirm the account at the registrar belongs to you | ☐ |
| Server / hosting admin access | Log in with your own password | ☐ |
| Third-party accounts (payments, SMS, email, maps) | Verify that you are the account owner in each one | ☐ |
| Installation and technical documentation | Ask whether the documentation matches the current version | ☐ |
| List of environment variables and secret keys | Receive them securely, then rotate them | ☐ |
| Components used and licence list | Check whose name paid licences are registered under | ☐ |
| Design source files | Receive the editable files | ☐ |
| Admin user accounts | Close the developer's accounts or change their passwords | ☐ |
Switching software development company: steps for a safe transition
Whatever your reason for switching, the goal is for your business to keep running without disruption. Moving step by step rather than in a rush prevents both data loss and unnecessary disputes.
- Read your contract. Note the termination terms, notice periods, handover obligations and any outstanding payments. Get legal advice if needed.
- Secure access first. If ownership of the domain, server and third-party accounts is not with you, take them over before ending the relationship.
- Take a full backup. Store an up-to-date backup of the code and database somewhere under your control, with the current developer's knowledge.
- Have the new team run a technical review. The new company should review the code, documentation and server setup and list what is missing. Missing handover items come to light at this stage.
- Request missing items in writing. Ask the previous developer for the missing items, in writing and dated, referring to the handover list in the contract.
- Plan a seamless switchover. If needed, the system is first tested on the new server, then the domain is pointed to it. Time the switch for your quietest business period.
- Close old access. Once the transition is complete, revoke all of the previous developer's account and server access and change the passwords.
Keeping communication with the previous team polite and in writing usually makes things easier. The other side also wants its work handed over properly; a clear list and a reasonable timeline create cooperation instead of conflict.
How Fietto Creative handles source code and data
We apply the rules recommended in this article to our own projects. In our custom software development process, the source code and data of the software we build belong to the client. When the project is complete, we hand over the source code and technical documentation. If sensitive business information will be shared and the client requests it, we sign an NDA before the project starts.
After go-live we provide support through a monthly maintenance contract. Maintenance is optional and is not tied to code ownership: even if you do not take maintenance, your code and data stay with you. The athlete management panel we built for Ortakçı Sports Club and the e-commerce platform and custom software for Mobilya Depom are among the projects we have run this way.
Our office is in Nilüfer, Bursa, and we work with clients across Türkiye and abroad. You can read more about us or explore the full process on our custom software service page. If you would like to go through a proposal you have received or your existing contract from a technical perspective, get in touch. For the legal assessment, remember to get your lawyer's opinion as well.
Frequently asked questions
If I pay for custom software, do I automatically own the source code?
Not always. As general information, software is usually protected as a copyright work, and in many countries, including Türkiye, the transfer or licensing of economic rights must be made in writing with the rights listed individually. If your contract has no clear clause on this, having paid may not be enough on its own to give you ownership. Rules differ by country, so review your situation with a lawyer.
Is receiving the source code enough?
No. Alongside the code you should receive a database backup and schema, server and domain access, third-party service accounts, installation and technical documentation, and a list of the libraries used and their licences. Without these, another team may not be able to run the code.
Should I sign an NDA with a software development company?
If you will share sensitive information such as business processes, customer lists or pricing structures, a non-disclosure agreement makes sense. The NDA should clearly state what counts as confidential, how long it stays confidential and what happens in case of a breach.
From a data protection point of view, is the software company a data processor?
Usually you decide why and how personal data is processed, so you are the data controller. If the software company accesses or hosts that data on your behalf, in most cases it acts as a data processor. Turkey's KVKK and the EU's GDPR both use similar roles, but rules differ by country. The roles should be written into the contract and checked by a lawyer.
If I stop the maintenance contract, will I lose the code?
Not if your contract is set up correctly. Source code ownership and maintenance are separate matters. Maintenance is a service; when you end it, your code, data and access should stay with you. Make sure the contract does not link the two.
