15 Clauses to Check in a Software Development Contract: A Pre-Signing Checklist

In brief: A good software contract puts in writing the project's scope, deliverables, schedule, payment plan, ownership, confidentiality, quality and support obligations, and how you part ways if things go wrong. Most disputes in software projects come not from code quality but from vague scope, unwritten ownership, muddled warranty/maintenance wording and a payment plan not tied to progress. This guide gives the 15 clauses to check before signing, with a “what does a good example look like?” note for each. Important: This content is general information and is not legal advice; consult a lawyer about your contract's scope, the applicable law and any sectoral obligations. A contract is not a sign of mistrust between the parties; it is a way of writing down their shared expectations.

Last updated: October 2026

Why does the contract matter so much?

While a project goes well nobody looks at the contract; when a problem appears, what is written is what counts. These situations arise from gaps in the contract:

• “This was already in scope” / “no, it was extra work” arguments
• Who is responsible for what when there is a delay
• Who owns the source code and how it is delivered
• Whether fixing bugs after the warranty period is paid or free
• How the project is handed over if you part ways with the vendor

The contract is the written assurance of the verbal answers you received during vendor selection.

The 15 clauses

1. Parties and project definition

The parties' official names, tax details, authorised representatives and a short, clear description of the project. A good example: The project's purpose and main output are written in a sentence or two; the annexes (quote, scope document) are defined as part of the contract.

2. Scope and “out of scope”

The feature list, screen/flow descriptions, integrations and deliverables of the work, and what is explicitly out of scope. A good example: The scope document is attached to the contract and binding; “out of scope” items are written down. For scope clarity, see our product owner role article.

3. Deliverables and acceptance criteria

What is delivered, in what form (working software, source code, design files, documents) and the conditions for a delivery to count as “accepted.” A good example: The acceptance criteria are measurable; time and procedure for acceptance testing are defined. For the testing process, see our acceptance testing (UAT) guide.

4. Duration, schedule and milestones

The start date, phases and delivery dates; client dependencies (content, approvals, access) and how their delay affects the schedule. A good example: Both sides' delay responsibilities are balanced and clear; the method for moving the schedule is written down.

5. Fee and payment plan

The total fee, VAT treatment, currency and tying payments to phases/deliveries. A good example: A reasonable advance, remaining payments tied to working output; no large payment before you see a working version. For pricing models, see our pricing guide.

6. Change management

When a new request outside scope arrives, how is it submitted, priced and approved? A good example: Change requests are in writing; their impact (time/cost) is reported before approval; the unit price or calculation method is known.

7. Intellectual property and source code

Who owns the source code, design, documents and database, and when and in what form they are delivered. A good example: On completion of payment the source code and related rights are transferred to the client; licence terms are clear for the vendor's pre-existing general components (libraries, frameworks). Read restrictive wording such as “right of use only” carefully.

8. Third-party components and open source

The licences of the open source and commercial components used must suit your use, along with the obligations arising from them. A good example: The vendor provides a licence list of the components it uses and is responsible for licence incompatibility.

9. Accounts and access

In whose name accounts such as domain, hosting, payment provider and maps/SMS will be opened; administrator access. A good example: Accounts in the client's name; the vendor added as an authorised user; access can be removed at the end.

10. Confidentiality (NDA) and personal data protection

Confidentiality of commercial information; if personal data will be processed, the parties' roles (controller/processor), security measures, breach notification, return/deletion of data at the end of the term. A good example: NDA provisions and data processing terms are clear; the breach notification period is specified. Consult your legal adviser about KVKK obligations. For security expectations, see our security guide.

11. Quality, testing and security commitments

The testing, security checks and performance work the vendor will do (and whether it is included in scope). A good example: Testing and security work is defined in scope and tied to the acceptance criteria.

12. Warranty period and bug fixing

The warranty's start (go-live or acceptance?), duration, scope and what is outside warranty. A good example: Bugs within scope are fixed free during the warranty period and within a stated time; out-of-warranty situations (client intervention, new features, third-party changes) are clear. For the difference between warranty and maintenance, see our maintenance and SLA guide.

13. Maintenance and support

Post-launch maintenance scope, SLA (response/resolution times), working hours, fee and the term/renewal of the agreement. A good example: Maintenance is defined as a separate annex or section; priority levels and times are written.

14. Limits of liability and delay/penalty clauses

The parties' limits of liability, sanctions for delay (such as a daily delay fee) and provisions on indirect damages. A good example: Liability limits are reasonable and mutual; the delay sanction is proportionate and force majeure is defined. This clause requires legal expertise.

15. Termination, handover and dispute resolution

In which cases the contract can be terminated, the status of the work and code produced up to that point on termination, handover assistance and the dispute resolution route (competent court/arbitration). A good example: On termination, the code and documents corresponding to the part already paid for are delivered; a reasonable support period is defined for handover. For the scenario of a project in trouble, see our project rescue article.

Summary checklist

Preparation before the contract

Before signing:

1. Take the scope document and quote into the contract annex.
2. Clarify the key points (ownership, accounts, payment, warranty, maintenance) in writing, not verbally.
3. Have your lawyer review the contract; especially the liability, penalty and dispute clauses.
4. Have someone with technical understanding look it over too (deliverables, acceptance criteria, components).
5. Clarify vague wording before signing: “within a reasonable time,” “where necessary,” “as deemed appropriate.”
6. Ask about terms you don't know; our software terms glossary may help.

Red flags (in the contract)

• No source code transfer or limited to a “licence”
• Accounts in the vendor's name
• A demand for full payment up front
• Scope too general (“a website will be built”)
• Warranty and maintenance muddled; unclear what is paid
• A one-sided right of termination only for the vendor
• No acceptance criteria or acceptance at the vendor's discretion only
• No confidentiality/personal data clause
• Handover assistance not considered at all

If you see several of these, ask for corrections or evaluate alternative vendors.

Contracts and agile projects

In phased and agile projects scope becomes clear over time; that does not mean there is no contract. These structures work:

• Framework agreement + phase-based annexes: General terms fixed, a scope/fee annex for each phase.
• A discovery phase at a fixed price, then development phases.
• In hourly/monthly models: A cap, reporting, acceptance and “continue/stop” points.
• A clear change management and prioritisation process.

The MVP approach and a phased payment plan fit this structure.

Transparent contracting with Aktaş Digital

We see the contract as a tool that clarifies shared expectations: we write the scope and cost breakdown, deliverables, payment plan, confidentiality/NDA terms and support obligations clearly, and discuss source code and account ownership at the start of the project. We also recommend that you consult your own legal adviser on the legal side of your contract. To get a quote and scope breakdown for your project, you can use our quote form. Our related services: web applications, SaaS platform development, CRM and ERP.

Frequently Asked Questions

Can I work with just a quote and no contract?

A quote may contain some binding elements, but it may not sufficiently cover matters like scope, ownership, confidentiality, warranty and termination. For medium and large projects, a written contract (or contract terms that complement the quote) is recommended.

Do I have to pay extra to receive the source code?

It depends on your contract's provision. The standard expectation for most clients is that the source code is transferred when the fee is paid. Have this written explicitly in the contract; uncertainty creates disputes later.

Should I include a late-delivery penalty?

A delay sanction can encourage adherence to the schedule; but delays caused by the client and force majeure should be regulated separately. Proportionate and mutual provisions are healthier; determine them with your legal adviser.

How long should the warranty period be?

It varies with project type and complexity; what matters is that the start date, scope and out-of-warranty cases are clear. Settle on a reasonable level by discussing it with the vendor.

Is a KVKK clause needed in the contract?

Yes, if the project will process personal data; there should be provisions on the parties' roles, security measures, breach notification and data return/deletion. Consult a legal adviser for details.

What should I do if the vendor won't give me a contract draft?

You can send your own draft or terms, or at least have the items above added to the quote and scope document to reach a written agreement. A vendor that refuses to write a contract can be a red flag.

Conclusion

A good software contract clarifies scope, ties payment to progress, keeps ownership with you, secures quality and support in writing and protects your project even if you part ways. Compare the 15-clause list against your quote and contract, clarify vague points before signing and have your lawyer review it. The first thing you can do today: check whether source code ownership, account ownership and warranty/maintenance wording are written in the quote you hold.