Software Development Contract: Who Owns the Source Code, and What to Check Before Signing

In short: in a software development contract, always clarify three things: who owns the source code and the copyright, what counts as acceptance, and what happens after launch. This is general information, not legal advice; have a lawyer review the contract.

Many companies pay for a system without knowing whether it is really theirs. Later, when they want to move to another developer or the developer disappears, it turns out the code isn't theirs or they have no access.

1. Source code and copyright

Copyright normally stays with the developer unless the contract says otherwise. Clarify:

• whether the developer transfers the economic rights, or you only receive a license to use;
• whether the license is exclusive and unlimited (in time, territory, modification);
• whether you receive the full source code, not just the compiled, running version;
• what about third-party and open-source components (they have their own licenses).

2. Access and documentation

A system is more than code: hosting, domain, database, API keys, CI/CD. The contract should state that these are handed over and that documentation (setup, architecture, operation) is part of delivery.

3. What counts as acceptance?

Define acceptance criteria up front: which features must work, under what tests, with what performance. This protects you from disputes about whether the work is done. I described the project process here.

4. Price and payment schedule

• Fixed price: for a precise scope. Ask for an itemized feature list.
• Hourly rate with a budget cap: when requirements evolve.
• Milestone-based payment: not a single sum up front.

You can read more about pricing here.

5. Bug fixes and warranty

How long are bug fixes free after launch? (With me it's 30 days.) What counts as a defect and what as a new request? How does maintenance work afterwards? There's a separate article on maintenance.

6. Confidentiality and data protection

An NDA for business and personal data. If the system handles personal data, a data processing agreement may be required (GDPR).

7. Change management

Requirements will change. The contract should describe how you handle it: who requests, what the impact on time and cost is, who approves.

8. Exit and handover

What happens if the collaboration ends? How is the work handed to another developer? A good contract settles this too, so you aren't exposed.

Red flags

• the code isn't handed over, it's "just run for you";
• no itemized scope;
• no acceptance criteria;
• the developer hosts the system on their own servers and gives you no access.

In my engagements, the source code, documentation and access are always yours. If you'd like to know more, let's talk for 30 minutes or see how I work. For choosing a partner, these 10 questions also help.