The software development contract: what to regulate

A poorly drafted software development contract almost inevitably breeds conflict: who owns the code, what was actually included, who pays for delays. In Switzerland the Code of Obligations provides a framework, but leaves many points to the will of the parties. A clear contract is not about arguing better: it is about not arguing at all. Let us look at what to regulate, from the perspective of both the client and the developer.

The nature of the contract

First of all, you need to understand what kind of relationship is being created. In Switzerland, bespoke development often resembles a contract for work and services (Werkvertrag), in which the supplier must deliver a working product, not merely make hours of work available. Other models, such as a lump-sum arrangement with an obligation to achieve a result, or time-and-materials work, distribute risk differently. Confusing “I pay you for a result” with “I pay you for the time you put in” is at the root of many disputes.

Code ownership and rights

This is the point on which parties most often find themselves in disagreement once the work is finished. The following must be clarified in writing:

Who owns the rights to the software developed: without an express assignment, the client risks not holding all the rights it believes it has.
The source code: is it delivered, or does it remain with the supplier? It is a huge difference for the client’s future freedom.
The supplier’s pre-existing components reused in the project: as a rule they remain the supplier’s, but a clear licence to use them in the client’s favour is needed.
The open source components included: these must be declared, together with their licences and the constraints they entail.

The client wants to be able to use, modify and further develop the software, even with a different supplier. The developer wants to protect its own reusable know-how. The contract finds the point of balance.

Specifications, acceptance testing and changes

Most conflicts arise from “this isn’t what I asked for”. To avoid this:

Attached specifications: what the software must do, in sufficient detail. It is the anchor for every subsequent discussion.
Acceptance criteria: how it is verified that the result conforms, and what happens if it does not.
Change management: a procedure for change requests during the work, with an impact on timing and price. Without it, every “small addition” becomes a dispute.
Milestones and payments: linking instalments to verifiable phases protects both parties.

Timing, warranty and maintenance

Timing and delays: realistic deadlines and the consequences of delay, distinguishing causes attributable to the supplier from those of the client (for example missing content or approvals).
Defect warranty: the duration and manner in which defects are corrected after delivery.
Maintenance and further development: maintenance is a different contract from development. Response times, corrections, updates and costs must be defined, in writing and separately.

Liability, data and exit

Liability limits: within the limits permitted by Swiss law, caps and exclusions are defined. Liability for intent and gross negligence cannot be excluded.
Data protection: if the software processes personal data, the contract must regulate the roles and obligations in this area.
Confidentiality: information and materials exchanged must be protected.
Termination and exit: how the relationship ends, what is handed over (code, documentation, credentials) and how the transition to another supplier takes place. The exit clause is the one that proves decisive when relationships sour.

In summary

Define the nature of the contract: result versus time-and-materials changes the entire risk profile.
Regulate code ownership, source code, pre-existing components and open source in writing.
Anchor the project to specifications, acceptance criteria and a change procedure.
Do not forget warranty, separate maintenance, liability, data and the exit clause.

How we help you

We draft and review bespoke software development contracts, from the perspective of both the client and the developer, with attention to code ownership, acceptance testing and exit. Let’s talk about your contract.