Software Agreements with Clients

For a technology or design company, a client agreement is the most critical document that comprehensively adjusts your business model, determines the strength of the negotiating position vis-à-vis clients, and outlines weak spots that can eventually lead to disputes. Most software and design supply agreements contain a number of specific provisions, but in this article, we only deal with the most common ones. Setting them up correctly will strengthen your position, reduce potential risks, facilitate collaboration and help prevent conflicts. For practical reasons, when we use the term software, this also includes UX / UI design.

Keep in mind that software, its development and operation remain a mystery to most of your clients and lawyers. Therefore, they will often insert proposals detached from reality into contracts. The best weapon is evangelism, that is, patiently explaining and educating clients and their lawyers.

1. Purpose of the Agreement

The subject of the agreement shall determine the mutual performance of the parties. Based on the agreement’s wording, it will also be subject to the relevant laws, which further specify the agreement, often without your knowledge. Although the subject of the agreement looks innocent, like legal fudge, it has far-reaching implications for the entire relationship with the client. Incorrect or insufficient specification of the obligations of you and your clients in the subject of the agreement is a frequent cause of disputes.

Development studios creating software for a client must initially decide if they work according to:

• Time & material: The preferred option for developers, but clients are afraid of it, as they do not have a predetermined price. This type of cooperation is only suitable for agile development. Its advantage is that both parties make better use of their time, as they do not spend it on discussions about the scope of the project. They can thus put more focus on building the product. The client, of course, needs 100% insight into the project. It is often necessary to patiently convince your clients about the benefits of this regime of cooperation.

• Fixed scope & fixed price: The preferred option for clients, as they have certainty in the total price. With insufficient product specifications, it is a nightmare for developers that can overwhelm project management with disputes about which features and functionalities are “in the scope”. We recommend agreeing on this regime if there is a good product specification or if a UX sprint is agreed, during which the product will be specified within the boundaries of the set budget.

2. IP Protection

The value of the software lies in IP protection, which we discuss more broadly in the previous edition of Playbook newsletter. The terms of use and transfer of IP are set forth in a licence clause (or a separate agreement), which can range from a time-limited right to use the software to an exclusive licence where you agree to refrain from any use of the work and allow the client to freely sell and further sublicence the software.

A rule of thumb when transferring IP: only transfer it to the extent and for the time necessary.

IP to the software is the basic protection against insolvent clients. We recommend granting an IP licence only after full payment of the agreed fee or release IP in parts following individual remuneration payments.

IP protection is related to the protection of trade secrets in the form of NDAs (non-disclosure agreements). This should be reciprocal and limit the number of entities that have access to it to the necessary minimum. You should sign the NDA before starting negotiations with the other party.

3. Liability for Defects and Warranty

Software, unlike traditional “works” such as, for example, a house, is not perishable and should therefore not be covered by a “quality warranty”. At the same time, expecting the existence of flawless software with the constant development of connected software and hardware is a utopia. Unfortunately, contracts often provide guarantees that the software will be error-free for years. This often leads to unnecessary disputes over software warranties. If a client is interested in receiving support and updates for software, you should ideally enter into an SLA, which we discuss below.

When contracting for software development, the client has the right to identify defects in the work and request the elimination of defects (free of charge), a discount from the price or termination of the agreement. Removing the so-called “bugs” can be included under a paid development or maintenance regime (SLA).

It is good practice to set a testing period (in the range of several weeks), during which the client has the opportunity to test the software and report any defects. At the end of testing, the software will be accepted by the client. In this way, you can avoid lengthy disputes about who is obliged to pay for a defect.

4. Liability for Damage

In the event that one of the parties causes damage to the other, either due to defective performance or breach of contractual obligations, it is obliged to compensate for the incurred damage expressed in money. In most jurisdictions (SK, CZ, UK, US), the injured party can claim damages from the other party without limits in the amount of the actual damage and lost profits.

Limitation of Liability

We recommend setting a maximum amount of liability for damage in contracts, e.g. up to the value of the remuneration. We also recommend excluding liability for loss of profits, which can be in millions of euros for large clients. In this way, you will prevent a situation where one “failed” order could endanger the existence of your entire company.

Contractual Penalties

Contractual penalties are a common ailment. In general, they should motivate the supplier to perform in a timely and high-quality manner, but in reality, they present an unnecessary duplication in the liability provisions. They are mostly prohibited in UK and US law.

Insurance

Good protection against liability for damage is quality insurance. In fact, some clients will ask for it directly from you. Insurance contracts are complicated and contain many exclusions, so always consult your lawyers before concluding them. Existing insurance can also help you limit your contractual liability to the amount of insurance.

5. Payment Terms

Always pay attention to 2 metrics, i.e. your liquidity and the solvency of the client. For technology companies, we distinguish 2 types of clients who approach payment terms differently:

• Corporations – with corporate players you do not have to worry about their insolvency, on the contrary:Pay special attention to the due dates. Internal invoice payment processes are complicated, so maturity dates are often in months. This is how you provide a de facto short-term loan to corporations. From our experience, even with large global corporations, you can agree on a 30-day maturity. The other problem is blocking the payment of the sum by disputing its amount or the fulfilment of your obligations.

Therefore, adjust the payment terms so that the client can block only the disputed part of the remuneration and thus mitigate the effects on cash flow even in the event of an ongoing dispute over the project.

• SMEs – tend to be more flexible with regard to maturity, but care must be taken with their ability to pay / solvency. The best protection is advance payments in the amount due. Even for small projects, it pays off to write the basic elements of the agreement into a simple order. You would not believe how much light such a document can bring to the dispute. ??

6. Data Protection

Be careful if you work with your clients’ personal information. You should agree on their administration as well as the internal processes for handling their data in a separate agreement. We talk about this topic more elsewhere in the Playbook.

7. Non-solicitation of Employees

Companies invest considerable resources into recruiting and retaining quality wokers. The purpose of the non-solicitation clause is to contractually protect these important investments. Think of 2 main elements:

• Sufficient scope to limit the possibility of circumventing them “creatively” (e.g. through a third party or other forms of contractual relationships).
• A contractual penalty set in such a way that the other party is incentivised to comply with these provisions and at the same time that its amount covers your losses in case of a potential breach (e.g. when taking over workers, the amount of the contractual penalty should reflect the costs of recruiting and training the employee and the lost revenue for a period of 6-12 months).

8. Non-compete

By working with suppliers and our own staff, you entrust them with valuable know-how, usually protected by NDAs. However, with sensitive information and processes, you may be interested in preventing your suppliers or colleagues from collaborating with your competitors. It’s easier with B2B relationships. The duration of the non-compete obligation typically lasts from 6 months to 2 years. However, this exclusivity is not cheap and will not be easy to enforce when the contract is negotiated. For employees (B2C), the Labour Code sets out a number of restrictions, including the duration and also the obligation to pay compensation to former employees for the duration of the non-compete obligation.

Update: Beginning September 4, 2024, all post-employment noncompete agreements will be prohibited, with the aim of promoting greater labor market flexibility and innovation.

9. SLA

A service level agreement (SLA) is a part of a contract or a separate document in which you and the client adjust the level of support after the software is delivered. Its scope can range from occasional updates in case of major changes to 24/7 support by dedicated teams. A good SLA should determine:

• Service level: contains the specification of included support, conditions of availability of support, division of incidents according to priority, deadlines for their resolution, escalation procedures, etc.
• Management: includes a way to evaluate the level of provided support, ticketing, reporting, the process of resolving any disputes and an agile mechanism to update the agreement as needed.

Do you need help with your documentation? Download our templates: https://playbook.sparring.io/en/template/