Short answer: ten clauses, and the one most often forgotten is "source code is written separately"
A software development contract needs ten headings in writing: scope and deliverables, price and payment, schedule, acceptance and defects, intellectual property and license, source code, maintenance and support, confidentiality and personal data, security, termination and exit. The clause most often skipped is who will own the source code: under the Law on Intellectual and Artistic Works, contracts on financial rights must be in writing and the transferred rights must be listed separately. "The source code will be delivered to you" is therefore not enough on its own.
This article is not legal advice; show your contract to a lawyer. Article numbers link to the relevant statutes; for detail and interpretation, consult a specialist.
| # | Heading | Key question |
|---|---|---|
| 1 | Scope and deliverables | What will be delivered, and what will not? |
| 2 | Price and payment | Fixed or time-based, and when is it paid? |
| 3 | Schedule | Phases, dates, consequence of delay |
| 4 | Acceptance and defects | How is it tested, and when must a defect be notified? |
| 5 | Intellectual property and license | Which right belongs to whom, and which is a usage permission? |
| 6 | Source code | Delivery, documentation, third-party components |
| 7 | Maintenance and support | Duration, scope, response time, fee |
| 8 | Confidentiality and personal data | Whose data is it, and who is responsible? |
| 9 | Security | Which security measure, and how is it verified? |
| 10 | Termination and exit | How do code, data and documents come back when you part? |
The legal nature of the contract
Software development contracts are often tied to the work contract (eser sözleşmesi) provisions of the Turkish Code of Obligations: TBK Article 470 defines a work contract as one in which the contractor undertakes to produce a work and the client undertakes to pay a price in return; Article 471 requires the contractor to do the job loyally and carefully, in line with the professional and technical rules a prudent contractor taking similar work would follow. In practice, whether a contract is a work contract or a service contract is a separate debate; this distinction is explained, in a law firm's article, based on a decision of the Court of Cassation's General Assembly of Civil Chambers. For ongoing development and maintenance the nature may change; so settle with your lawyer what the contract is.
The 10 clauses
1. Scope and deliverables: what will be done, and what will not?
List the deliverables one by one (modules, screens, integrations, documentation, training) and also list what is out of scope. Vague scope is the first cause of later disputes over extra work. Gather scope in an annex document and write a "change management" rule: if scope changes, how are time and price updated?
2. Price and payment: fixed or time-based?
Under TBK Article 480, if the price is fixed, the contractor cannot ask for the price to be raised even if the work takes more effort and cost than expected; but if circumstances that were unforeseeable at the start, or foreseeable but not taken into account by the parties, make it extremely hard to carry out the work at the fixed price, the contractor may ask the judge to adapt the contract and, if that is not possible, to withdraw from it. Under Article 479, the client's duty to pay becomes due on delivery of the work; with delivery in parts, the price of each part becomes due on delivery of that part. Practical consequence: tie payment to phases, write what each delivery earns, and for time-based work (hours/days) set a ceiling or a budget approval. To set aside a first phase as discovery, see what to prepare before commissioning custom software.
3. Schedule: phases, dates and the consequence of delay
Write the delivery date of each phase, the consequences of delay depending on who caused it (does the date move if the client's approval is late?), and the penalty or extra-time mechanism. Because time estimates are uncertain, a written plan with phased reassessment helps.
4. Acceptance and defects: how is it tested?
TBK Article 477 says that after the work is accepted, expressly or tacitly, the contractor is released from liability, except for defects the contractor deliberately concealed and that could not be noticed during a proper inspection. If the client neglects inspection and notification, the work is deemed accepted; if a defect appears later, it must be notified without delay, otherwise the work is deemed accepted. Under Article 478, claims over a defective work, other than immovable structures, are time-barred two years from delivery; twenty years apply if the contractor was grossly negligent. Applied to software: write the acceptance criteria (which scenarios must pass), the acceptance period and the defect notification method (email, support system); name the person who will run the acceptance test.
5. Intellectual property and license: which right belongs to whom?
FSEK Article 2 treats computer programs, in whatever form expressed, as works. Article 52 requires contracts on financial rights to be in writing and the transferred rights to be listed separately. So "the software belongs to you" or "the source code is delivered" is not enough on its own: the assignment of rights (which financial rights, to what extent), the usage license (duration, number of users, sublicensing) and the contractor's own pre-existing components must each be written separately. If the contractor will use its own libraries for other clients, decide that knowingly.
6. Source code: form of delivery and documentation
Write when, in what form (repository access, archive), with what documentation (installation, architecture, dependency list) and with which third-party components (open-source licenses) the source code will be delivered. Describing delivery as happening with every release rather than once keeps the code current even if the relationship sours. Keeping the code in an environment independent of the contractor is our suggestion; it has to be written into the contract.
7. Maintenance and support: duration, scope, response time
Write what maintenance includes (bug fixes, security patches, version compatibility; are new features excluded?), its duration, its fee, the support channels and response and resolution times. For adding the maintenance fee to total cost, the table in our ERP pricing: 5-year total cost article gives an example. For maintenance and support, see our support and maintenance page.
8. Confidentiality and personal data
KVKK Article 12 requires the data controller to take the necessary technical and administrative measures to prevent unlawful processing of and access to personal data; if the data is processed by another person on its behalf, the two are jointly responsible for the measures. If the contractor will access your data (test data, live data, maintenance), write that, with which measures and when it will be deleted. State whether the confidentiality obligation continues after the contract ends.
9. Security requirements
Ask the contractor which framework it follows for secure development: OWASP ASVS for web applications and NIST SSDF for secure software production (according to NIST's page it can be used by acquirers as well as producers) are common references. Writing into the contract "what level of verification will be done, how findings will be reported, how quickly a critical vulnerability must be closed" turns security from a claim into a criterion.
10. Termination and exit: what happens when you part?
TBK Article 484 is headed "termination against compensation": the law gives the client, under certain conditions, the option to withdraw from the contract by compensating the contractor's loss; see the statute for the conditions. In the contract, write for termination: how the price of work done to that point is calculated, how quickly and in what form the source code, data and documentation are delivered, whether handover help is given (paid or not, how many hours), and how deletion of the data held by the contractor is verified. A contract without an "exit" clause gives the contractor the bargaining power when the relationship ends.
8 questions to ask at quote stage
- Does the contract annex contain the scope and acceptance criteria?
- Are the assignment of rights and the usage license written separately?
- When, in what form and with what documentation is the source code delivered?
- Will the list and licenses of third-party and open-source components be provided?
- Maintenance and support: are response and resolution times and the fee written down?
- With what measures, and within what period, is access to personal data deleted?
- Against which framework is security verified, and how is it reported?
- How do code, data and handover help work on termination?
To use these questions in comparing quotes, see our off-the-shelf vs custom software decision matrix and our 2027 IT budget prioritization table. For your custom software project, see our custom software development page.
Frequently asked questions
Who owns the source code of the software?
It depends on what the contract says. Under FSEK Article 52, contracts on financial rights must be in writing and the transferred rights must be listed separately. Delivery of the source code, assignment of rights and a usage license are three separate matters; write all three and have your lawyer check them.
When must I notify a defect?
Under TBK Article 477, a defect that appears after acceptance must be notified to the contractor without delay, otherwise the work is deemed accepted. For claims over a defective work, the limitation periods in Article 478 apply (two years outside immovable structures; twenty years in case of gross negligence). Write the notification method and period clearly in your contract.
What should a maintenance contract cover?
It should state bug fixes, security patches, version compatibility, support channels, response and resolution times, duration and fee, and whether new feature requests are priced separately. Add the maintenance fee to your total-cost table as a yearly line.
What happens to code and data if the contract is terminated?
If the contract does not say, it is uncertain. Write up front the delivery of source code, data and documentation, handover help and the deletion of data given to the contractor.
If you would like to go through your contract clauses and quote comparison together, get in touch.
Sources: Turkish Code of Obligations, Articles 470-484 (Law No. 6098, Turkish Insurance Association statute compilation), Law on Intellectual and Artistic Works (Law No. 5846, Articles 2 and 52), Law No. 6698 on the Protection of Personal Data, Article 12 (Ministry of Justice), Work Contract, Conditions and Elements (Attorney Baran Doğan), OWASP Application Security Verification Standard (OWASP), Secure Software Development Framework (NIST)
Cover photo: Vitaly Gariev / Unsplash