Are you commissioning custom software or SaaS?

Decision framework: are you buying a product or a service

The first question is not legal, but operational. Custom software means you are paying for the creation of something that did not exist before, and you want to retain it. SaaS means you are renting access to a ready-made solution that the supplier operates and develops for all its customers.

This difference has three practical consequences. With custom development, the key issues are rights to the code and documentation; with SaaS, it's about availability, data, and exit conditions. With development, you are vulnerable at the moment of handover; with SaaS, you are vulnerable throughout the entire period of operation. And with development, the biggest risk is getting something that no one else can take over; with SaaS, it's that the supplier will unilaterally change the terms.

Most real-world projects are hybrids: a ready-made platform plus custom modifications, and it is precisely with these modifications that it often turns out the contract only addresses one of the two parts. The practical solution is to describe both layers separately and, for each, to specify who holds the rights, who is responsible for functionality, and what applies after termination. We cover the operational SaaS layer in detail in the article Contractual Assurance of Cloud Service Availability and Quality (SLA).

A fourth variant that companies often encounter later is development using generative tools. In that case, it is crucial to know what the supplier used to create the code, as this affects what they can actually hand over to you. We discuss this issue in the article Software Development Using Artificial Intelligence – Who Owns the Code.

A step-by-step guide

The order of the steps follows the negotiation phases. Those who skip them pay the price during operation.

The first step is to describe the output in a way that can be measured. The specification should include functions, performance parameters, and scenarios for testing. Phrasing like "the system will be user-friendly" will not hold up in an acceptance protocol, whereas "response time of under two seconds with fifty concurrent users" will.

The second step is to resolve the rights to the code, in writing and before signing the main contract. Decide whether you need to exercise economic copyrights to the code or if a sufficiently broad license is enough for you, and if so, to what extent: for how many users, for how many installations, with the right to give the code to a third party who will develop the system instead of the supplier.

The third step is acceptance. The contract should specify who performs the test, how long it takes, what happens in case of a partial failure, and when the work is considered accepted even without a signature. Without this, disputes arise as to whether the work was completed and handed over and whether the corresponding part of the price is due. Under Czech legislation, signing the protocol is not a condition for payment, but the contract can make it one.

The fourth step is operation: availability, response times, service windows, and penalties for non-compliance. Here, it is worthwhile to set penalties as automatic credits, not as compensation for damages that the client would have to prove.

The fifth step is to secure yourself in case the supplier goes out of business. The classic tool is a source code escrow with a third party, with defined release conditions. Escrow without up-to-date documentation is useless, so the contract must include the obligation to deposit the documentation and the current build as well.

The sixth step is the exit. The contract should include the format in which you will receive your data, the deadline for its release, the period of cooperation after termination, and the price for assistance with migration. For custom development, the exit is purely a matter of the contract, and without an agreed price, it becomes a negotiation under pressure.

However, for cloud and SaaS services, the exit is no longer determined solely by the contract. As of September 12, 2025, Chapter VI of the EU Data Act will apply, which requires data processing service providers to remove obstacles to switching to another provider and to enable data export. Switching fees are temporarily limited to the costs directly associated with the switch and are to be completely abolished from January 12, 2027. When negotiating, it is therefore worth checking whether the draft contract respects these rules or conflicts with them.

The seventh step is the change process. Without a described procedure for change requests, changes are handled by email, and a dispute over what was included in the price is certain. Therefore, the contract should specify who approves a change, the deadline by which the supplier will provide a work estimate, and what happens to the deadline if the client does not approve the estimate.

What is standard practice and what is a red flag

In healthy projects, it is common for the development price to be divided into phases linked to partial acceptances, with the final part being paid only after the system goes live. It is also common for the supplier to be liable for defects during the warranty period while simultaneously providing paid support; these are two different things and should not be merged into one.

For SaaS, the standard is availability described by a single monthly figure, a definition of planned downtime that is not counted towards availability, and credits for non-compliance. It is also standard for the supplier to be able to change features but not to lower the agreed service level, and to provide advance notice of any changes.

There are three red flags, and you will spot them as soon as you read the draft contract. The first is a contract that makes no mention of source code or documentation, because this means that a takeover of the system by another supplier will not be technically possible. The second is a supplier's liability limited to the amount of the monthly payment, which for an annual operation means they are practically not liable for any damage caused.

The third red flag is tying data to a format that you cannot read elsewhere. The phrase "data will be released in the format used by the provider" means, in practice, an export that you will pay to process twice. The provisions on personal data processing should be read with the same logic; we cover them in the article SaaS Platform in the EU.

Where the legal line is drawn

The legal regulation for software is stricter than companies expect in some respects, and more accommodating in another.

Under Section 58(7) of the Czech Copyright Act, computer programs and databases are considered employee works even if they were created by an author on commission, and in such a case, the client is considered the employer. This means that for a freelance programmer who wrote the code on your order, you exercise the economic rights, unless you have agreed otherwise.

However, the situation changes when the supplier is a software company. If its employees write the code, the company, as the employer, exercises the economic rights under the same provision, and the rights are transferred to you only to the extent specified in the contract.

In practice, moreover, the supplier often combines the work of employees, freelancers, subcontractors, open-source libraries, and third-party components, so the entire chain of rights needs to be verified, not just the supplier's declaration. Therefore, even with a freelance programmer, the contract should include the handover of the source code, documentation, authorization for modifications, and a list of third-party components used.

For works to which this rule does not apply, Section 61 of the Czech Copyright Act states that the author has granted a license only for the purpose arising from the contract. Use beyond this scope requires a license agreement. For graphics, texts, or interface designs supplied with the software, this is an often-overlooked detail.

The license agreement itself has a legal minimum. Under Section 2358, the licensor grants a license to the agreed limited or unlimited extent, and the licensee undertakes to provide remuneration, unless otherwise agreed; the contract requires written form for an exclusive license. The scope must therefore be described, otherwise it will be a matter of dispute.

The exit is also affected by the rule on license assignment. Under Section 2364 of the Czech Civil Code, the licensee may assign the license to a third party only with the licensor's consent, which requires written form. In the case of a transfer of a business or its independent part, consent is required under Section 2365 only if it was specifically agreed. Anyone planning to sell their company or spin off a division should address this point when signing the IT contract.

The rules on work then apply to acceptance. Under Section 2610 of the Czech Civil Code, the right to payment of the price for the work arises upon its completion, and if the work is accepted in parts, the right to payment for each part arises upon its completion. According to Section 2605, the work is completed if its fitness to serve its purpose has been demonstrated, and if the client accepts the work without reservation, a court will not grant them the right arising from an obvious defect if the supplier objects to the late claim. Therefore, signing the acceptance protocol is not a statutory condition for the right to the price to arise, but the contract can link the due date to it, which is why its form is negotiated.

The final line is the limitation of liability. Under Section 2898 of the Czech Civil Code, no account shall be taken of an agreement that excludes or limits in advance the obligation to compensate for harm caused to a person's natural rights, or caused intentionally or through gross negligence. Therefore, an agreed liability cap does not apply to these cases, no matter how the parties set it.

Final summary

An IT contract should be written starting from the end. First, answer what you need to have in hand on the day you part ways with the supplier: the source code, documentation, data in a usable format, and someone to take over the system. Only then should you address the price and deadlines. Write measurable acceptance criteria, describe the exit process including the price for assistance, and establish a change process right from the start.

The legal line is more favorable than companies realize in one respect, and stricter in another. For a programmer on commission, you exercise the economic rights; for a software company, you only have them to the extent agreed in the contract. The ARROWS law firm is insured for professional liability up to a limit of CZK 350,000,000 and negotiates IT contracts as part of its IT and Software Law, Cybersecurity service. Write to us at consultation@arws.cz.