Which clauses should a software development contract include?
A software development contract should put at least twelve subjects in writing: scope and annexes, acceptance tests, change control, the payment schedule, delivery dates and delay, intellectual property and source code, confidentiality, personal data, warranty and defect-fixing period, maintenance, termination and dispute resolution. When one is missing, the problem usually appears halfway through the project, when the two sides read the same sentence differently.
Legally, delivering a piece of software that does not yet exist for an agreed price is, in many cases, assessed under the contract-for-work rules of the Turkish Code of Obligations. Article 470 of Law No. 6098, the Code of Obligations, defines it as a contract in which the contractor undertakes to produce a work and the client undertakes to pay a price in return. Monthly maintenance, consultancy or hiring a team can fall under other contract types. A mixed structure within one project is therefore normal, and the contract should say which rules apply to which part.
The list below is a checklist for a business owner who searches for a "software development contract example" and then reads the draft with a lawyer.
Why does each of the 12 clauses matter, and what goes wrong?
| Clause | Why it matters | Typical mistake |
|---|---|---|
| 1. Scope and annexes | Fixes what will be delivered | Scope left in "the quote"; no annex |
| 2. Acceptance tests | Ties payment and liability to acceptance | No criteria, just "once satisfied" |
| 3. Change control | Extra requests affect price and time | Changes agreed verbally, unrecorded |
| 4. Payment schedule | Balances cash flow and risk | Whole price left until after delivery |
| 5. Delivery and delay | Sets dates and the cost of lateness | Client's own inputs have no dates |
| 6. IP and source code | Decides who may use the software and how | "All rights" written; rights not itemised |
| 7. Confidentiality | Protects trade secrets and data | No term; no duty after the contract ends |
| 8. Personal data (KVKK) | Clarifies roles and security duties | Roles unwritten; real data used in tests |
| 9. Warranty and defect fixing | Sets the fixing period after delivery | "Defect" undefined; period left open |
| 10. Maintenance and support | Keeps live software running | Maintenance never enters the contract |
| 11. Termination | Sets exit rules and handover | Fate of work done is not written |
| 12. Disputes | Chooses the route and forum in advance | No talks step first; forum unclear |
How are the scope, acceptance and change clauses written?
These three clauses have to work together. Scope says what will be built, acceptance tests say whether it was built, and change control says how new requests are handled after the contract is signed.
- Scope: List screens, user roles, integrations, supported devices and what is excluded. A technical specification or requirements document becomes an annex to the contract. Our guide to defining the scope of an AI project shows the same logic.
- Acceptance tests: State which scenarios run, with what data, in front of whom, and what counts as a "defect". Define severity levels (blocking, high, low) and which levels prevent acceptance.
- Change control: Every change arrives as a written request. The supplier answers with its effect on time and price, and no work starts until both sides approve.
The legal weight of acceptance is worth knowing. Article 474 of the Code of Obligations requires the client to inspect the work as soon as the ordinary course of business allows after delivery and to notify defects within a reasonable time. Article 477 says that once the work has been accepted, expressly or by conduct, the contractor is released from liability, and that if the client neglects to inspect and notify, the work is deemed accepted; defects the contractor deliberately concealed, and that could not be noticed on a proper inspection, are the exception. In short, receiving a delivery in silence can weaken the client's rights. Writing the acceptance period and the form of notice into the contract reduces arguments.
How are payment, delivery dates and delay handled?
The statutory default is that the client's duty to pay falls due when the work is delivered (Code of Obligations, art. 479). On a long software project the price is usually split into stages instead. Each stage is tied to a concrete deliverable and an acceptance condition. That way the supplier does not carry all the risk alone, and the client does not pay up front for a product that does not work.
The type of price should also be written down. Under a lump-sum price (art. 480), the contractor generally cannot ask for a higher price even if the job takes more effort than expected; only unforeseeable circumstances that make the work extremely difficult can lead to adaptation of the contract or withdrawal. This is why scope and change control matter even more in a fixed-price contract. Where an approximate price was set at the start and it will be exceeded to an excessive degree without the client's fault, art. 482 allows the client to withdraw from the contract.
One delivery date is not enough. Write stage dates, the last day for the client's own inputs (access, data, approvals) and that the schedule extends if those inputs arrive late. For delay, the statute lets the client withdraw without waiting for the delivery date if the contractor delays the work or it is clear the work will not finish on time (art. 473). The contract may also add a contractual penalty. Under art. 182, however, a judge reduces a penalty considered excessive of their own motion, so a reasonable, capped penalty is both fairer and easier to defend.
Who owns the intellectual property and the source code?
If the contract is silent, the question is open to dispute, and it is the clause that causes the most disagreements. Law No. 5846 on Intellectual and Artistic Works defines a computer program in art. 1/B and brings software within its scope as a work. Article 48 states that economic rights may be transferred, limited or unlimited in time, place and content; art. 52 requires contracts on economic rights to be in writing and the rights concerned to be listed separately. The last paragraph of art. 48 also contains a provision declaring such dispositions void where they concern a work that has not yet been created. This means a one-line clause such as "all rights in the software belong to the client" may not be enough on its own. How the clause is built should be assessed with a lawyer.
In practice, write the following distinction into the contract:
- Code written specifically for you: which rights (reproduction, adaptation, distribution and so on) are assigned or licensed, and for what period and territory.
- The supplier's pre-existing code and libraries: they stay with the supplier, and you receive a licence to use them. Open-source components follow their own licences and should be listed.
- Source code: will it be delivered, in what form (repository access, documentation, build instructions) and when? If not, depositing it with a third party (escrow) can be written in.
What should the confidentiality and personal data clauses cover?
The confidentiality clause covers trade secrets, source code, prices and customer data. It states a period that continues after the contract ends and lists the exceptions (public information, legal obligation). Personal data needs a separate clause, because during testing, support or maintenance the supplier may touch your employees' or customers' data.
Under art. 12 of Law No. 6698 (KVKK), the data controller must take the technical and administrative measures needed to ensure an appropriate level of security, and where personal data is processed on its behalf by another person, it is jointly responsible with them for those measures. The fourth paragraph of the same article provides that controllers and processors may not disclose the personal data they learn, or use it for purposes other than processing, and that this duty continues after they leave their role. If the supplier uses a cloud service or a server abroad, the transfer rules in art. 9 may also come into play. The contract should cover the parties' roles (controller, processor), the data types and purpose, security measures, use of subcontractors, the deadline for reporting a breach, whether real data may be used in test environments, and deletion or return of data at the end.
How are the warranty, maintenance and termination clauses built?
The warranty period is the time in which the supplier fixes defects found after delivery free of charge. The statutory defect rules give a framework: art. 475 lists withdrawal, a price reduction or free repair for a defective work, and art. 478 sets limitation periods running from delivery for claims over defects (two years for works other than immovable structures, twenty years where the contractor is grossly negligent). How these rules apply to software can be debated, so it is safer to write the definition of a defect, how to report one, the fixing time and the warranty period into the contract.
Maintenance is a separate subject. Warranty covers defects in what was delivered; maintenance covers updates, security patches, operating-system and library compatibility, monitoring and new releases. Write down the maintenance scope, the response-time targets (for example, how many hours to respond to a critical fault) and when maintenance starts and ends.
In the termination clause, set out in which cases and after what notice period either side may terminate, what happens to the work done and the source code, and what is paid. The statute lets the client terminate before the work is finished provided it pays for the part done and compensates the contractor for all its losses (art. 484). The dispute clause usually provides first for talks between named representatives and then for the competent court or another chosen route.
For example, how do the clauses work on a six-month project?
For example, take a hypothetical customer-portal project priced at TRY 1,000,000. The price is split into three stages: 30% on delivery of analysis and design, 40% when a working version passes acceptance testing, and 30% after go-live and a 30-day observation period. Delivery takes six months, and the contract makes it the client's duty to supply the data export file from the old system by the end of month one.
In month four the client asks for a new reporting screen. Under the change clause, the supplier replies within a week with "two extra weeks and a stated additional price". If the client does not approve, the scope stays as it was. The data file also arrives two weeks late, so the supplier gives written notice that delivery moves by two weeks; because the contract already anticipates this, no delay penalty arises. Acceptance testing finds two blocking defects; acceptance is given only after they are fixed, and the second payment follows then. The figures, percentages and periods are for illustration only.
What are the most common contract mistakes?
- Leaving the scope as "what the quote says" and not attaching the quote to the contract.
- Leaving out acceptance criteria and tying payment and liability to a vague "satisfaction".
- Covering intellectual property in one sentence, without separating the type of right, its period and delivery of source code.
- Using real customer data in test environments and not writing down the parties' KVKK roles.
- Confusing warranty with maintenance, or leaving maintenance out of the contract altogether.
- Signing a ready-made template unread. Articles 20 onwards of the Code of Obligations provide that general terms that go against the other party's interest do not become part of the contract unless certain conditions are met; reading before signing is still the safest course.
How Hatson Tech helps
Hatson Tech helps you write the technical side of the contract: we clarify scope and acceptance tests and set out the stage plan and the maintenance scope. The first meeting and discovery are free; we do not publish fixed prices, and a price follows once the scope is clear. Your own lawyer settles the final wording of the legal clauses. You can see how a project runs on our custom software development service page.
Contract review and due diligence is the work of Caseon, the product we built for legal teams; see the Caseon page for details. When choosing a supplier, you can also use the questions in our guide to choosing an AI supplier, and before replacing an old system our application modernisation decision guide.