What to look for in a software development contract
A software contract puts scope, acceptance, payment and source code ownership in writing. Scope, change control, warranty, data protection, termination and handover clauses.
A software development contract is the document that writes down what will be built, how it will be delivered, what will be paid, and who owns the resulting software. A good contract does not resolve disputes; it prevents them.
Most problems in software projects come not from bad faith but from ambiguity: “was this in scope?”, “does this count as done?”, “who has the source code?”. This piece lists the topics a contract should spell out. It is not legal advice; have a lawyer review the final text.
How should scope be written?
Scope is the most important clause. A general sentence such as “a corporate website will be built” is not enough. The contract should state:
- The list of pages, modules and features to be built.
- What will not be built (for example copywriting, third-party licences, extra languages).
- The integrations to be used and who is responsible for them.
- The devices and browsers to be supported.
The safest route is to base scope on a written brief; see how to write a software requirements brief.
Why do you need acceptance criteria?
“The project is complete” is a point of argument if there is no yardstick. For each delivery, write measurable acceptance conditions:
- Which scenarios will be tested?
- Who runs the acceptance test, and within what time?
- If a defect is found, how long is allowed for the fix?
- Whether delivery counts as accepted if no objection is raised within the period.
How should change control work?
Requests change in a software project; the problem is untracked change. The contract should contain this mechanism:
- A change is requested in writing.
- Its impact (time, budget, scope) is stated in writing.
- No work starts until both sides approve.
Without it, budget overruns are unavoidable; more in software project budget overruns.
How should the payment schedule be built?
| Approach | Advantage | Watch out for |
|---|---|---|
| Milestone-based payment | Each payment tied to a concrete delivery | Milestones must be clearly defined |
| Calendar-based payment | Predictable | The tie to delivery can weaken |
| Time-and-effort payment | Fits changing scope | A cap and reporting are essential |
Principle: tie payment to deliveries you can verify. Amounts and terms go in the commercial part of the contract; we give no figures here. For pricing logic, see software development pricing.
Who should own the source code and IP?
This is the most skipped clause and the most expensive to miss. It should state clearly:
- Whether source code is delivered, and at what point (with payment?).
- Who holds ownership or the right to use the software, and whether that right is perpetual or limited.
- Licences of third-party and open-source components.
- That the domain, server, store and other accounts are opened in the client’s name.
- The limit on generic components the contractor may reuse in similar work.
Our recommendation is that source code and account ownership be written explicitly into the contract. Otherwise, when you want to change contractors you may be left with nothing; we cover this in taking over a software project.
How should warranty and maintenance be arranged?
- Warranty period: the period after delivery in which defects are fixed free of charge. We give a 30-day bug warranty after delivery.
- Warranty scope: the line between a defect and a new request. A defect is behaviour that fails the acceptance criteria; it is not a new feature.
- Maintenance: how security updates, backups, monitoring and small improvements continue after the warranty; this can be a separate agreement or an annex.
- Response time: how quickly a critical issue gets a reply.
What do confidentiality and data protection require?
In a software project the contractor often has access to your data and sometimes your customers’ personal data. The contract should include:
- A confidentiality obligation and its duration.
- If personal data is accessed, the parties’ roles under the applicable data protection law (in Turkey, KVKK; controller and processor) and the processing terms.
- Where data is kept, who has access, and what happens to it when the project ends.
- The notification process in case of a security breach.
The details depend on the applicable law and the type of data; confirm with your lawyer.
Why do termination and handover clauses matter?
Even projects that start in good faith can end. Write in advance:
- Under what conditions each side may terminate, and the notice period.
- How work done up to that point is paid for and delivered.
- The handover process for source code, documentation and access: who delivers what, when and in which format.
- A reasonable obligation on the contractor to assist during handover.
A termination clause is for the bad scenario, but that is exactly when it earns its place.
Frequently asked questions
Can a software project run without a contract? Technically yes, but scope, payment and ownership stay unclear. Even a small project needs a short contract and a written scope.
Will I pay extra for the source code? That is a commercial negotiation. What matters is that the topic is written into the contract from the start; negotiating later is a weak position.
Is fixed price or time-based safer? For well-defined projects, fixed price is predictable. Where scope will change, working in two-week cycles and re-approving scope each cycle is more balanced.
Who should draft the contract? The contractor may prepare the draft; what matters is that you review the text with your own lawyer.
What happens after the warranty ends? The maintenance arrangement is discussed separately. If the accounts and source code are with you, you can also give maintenance to another team.
At Boygantech we put scope and delivery plan in writing before the contract. To plan a first call about your project, fill in our contact form or write to info@boygantech.com.
