Common mistakes in technology contracts

Most disputes in software projects arise not from bad faith but from the points where the contract stays silent. The parties start in good faith, and as the work progresses it turns out everyone's definition was slightly different — with no clause to resolve the difference.

Below are the places most often left blank in technology contracts.

A note on scope: the statutory references here are to Turkish law, which is the framework we work in.

1. What does "delivered" mean?

This is the most expensive ambiguity. Contracts contain a scope of work but no acceptance criteria. The developer says "I delivered it", the client says "it doesn't work", and both are right, because there is no yardstick.

What needs to be settled:

The concrete tests by which acceptance will be assessed
How many days the client has to accept
What silence during that period means (acceptance or rejection)
The period within which identified defects will be remedied
Whether partial acceptance is possible

Failing to state the consequence of silence leaves the project suspended indefinitely.

2. The price of scope change goes unwritten

New requests arrive in every project; that is not the problem. The problem is not writing down the procedure by which a request becomes a change of scope.

The contract should set out how a change request is submitted, who approves it, and how its effect on time and price is calculated. Without this, the developer either works for free or the relationship breaks down.

3. Intellectual property transfer is written incompletely

Under Turkish law this is where carelessness is punished most concretely.

Under Article 52 of the Turkish Copyright Act (FSEK), contracts concerning economic rights must be in writing and the rights transferred must be enumerated separately. A general sentence such as "all rights are transferred" does not satisfy this requirement; each economic right (adaptation, reproduction, distribution, performance, communication to the public) must be listed.

Two points are especially often missed:

Employees versus contractors. FSEK Article 18/2 provides that rights over works created by employees in the course of their duties are exercised by their employer. This provision does not extend to freelancers or external suppliers — a separate, express assignment is required with them. If part of your team is freelance, ownership of the code may not sit where you assume.
Moral rights cannot be assigned. Transfer is possible only for economic rights; writing that moral rights are also transferred does not make that part valid.

4. Open source components are never discussed

Almost nothing today is written entirely from scratch; every project carries libraries, packages and off-the-shelf components. Their licenses differ, and some may require you to release your own code on the same terms when you distribute your product.

Questions the contract should answer:

Will a list of third-party components be maintained?
Which license types are excluded from the outset?
Who bears the loss arising from a license breach?

This is not a theoretical risk. Datasets carry the same problem: the license of a dataset can directly constrain the commercial model of the product that uses it.

5. An SLA is written, but measurement is not defined

"99.9% availability" is not, on its own, a commitment. Without a defined measurement the number carries no meaning:

With what tool, and from where, will availability be measured?
Are planned maintenance windows counted?
Is the period assessed monthly or annually? (99.9% annually and 99.9% monthly are very different things.)
What follows if the commitment is missed — a penalty, a fee credit, a right to terminate?

Warranty and maintenance also get conflated. Warranty concerns the delivered work being free of defects; maintenance is the service provided afterwards. Their scope and price should be written separately.

6. The data protection clause is added at the end

Most software projects process personal data. Even so, the data protection clause usually lands at the very end as a single general paragraph.

What needs to be settled:

Which party is the data controller and which the data processor? This distinction drives the allocation of liability; under Article 12/2 of the Turkish Data Protection Law (KVKK) the controller is jointly liable together with the processor.
Are the processor's duty to stay within instructions, its use of sub-processors, and its confidentiality obligation set out in writing?
Is there a cross-border transfer? If a cloud provider's servers sit abroad, there is a transfer, and it requires the legal basis sought by KVKK Article 9 (standard contractual clauses, binding corporate rules, and so on). This is not a technical detail like "our server is in Frankfurt" — it is a legal situation requiring disclosure.
When the contract ends, will data be returned or deleted, and within what period?

That last item should be drafted together with the technical team: deleting some records may not be possible. For financial records, Article 253 of the Tax Procedure Law (VUK) and Article 82 of the Turkish Commercial Code (TTK) require longer retention. Where these conflict, the answer may be to sever the record from identity rather than delete it — but that has to be described accurately in the contract and in the privacy notice.

7. The liability cap is drafted too ambitiously

Contracts often carry clauses along the lines of "the contractor is liable for no damages whatsoever." Under Article 115 of the Turkish Code of Obligations (TBK), an agreement made in advance that the debtor will not be liable for its intent or gross negligence is absolutely void.

So a blanket exclusion, far from providing protection, is the first clause to fall in a dispute. A party seeking to limit liability is better protected by setting a reasonable cap (the annual contract value, for instance) and scope (excluding indirect damages) than by attempting to exclude everything.

8. There is no exit plan

Contracts regulate the beginning in detail and the end vaguely. Yet the end is where the real crisis sits:

Who keeps the source code, and in what form is it handed over?
Who takes over environment details, infrastructure access, the domain and DNS management?
How much support is provided during handover, and at what price?
In whose name were the third-party service accounts opened?

That last question causes trouble constantly in practice: if the domain or cloud account was opened in the agency's name, the client can find itself locked out of its own infrastructure when the relationship ends. The contract should state in whose name accounts are to be opened.

In short

A good technology contract is a document nobody reads for as long as the parties agree; its value appears when they stop agreeing. Acceptance criteria, the change procedure, express assignment of rights, data provisions and an exit plan — if those five are written, most of the rest is manageable.

If you'd like to review your existing contracts against these headings, get in touch.

This article is for general information only and does not constitute legal advice on any specific matter. References to legislation are current as at the date of publication.