From Contract to Dispute: How IT Businesses Can Structure Transactions and Resolve Conflicts — An Interview with REVERA Kazakhstan Experts

19.06.2026

An IT project rarely ends in exactly the same configuration in which it was described at the outset.

The business objective changes, new integrations appear, third-party services are connected, the technology stack is updated and, together with this, the legal picture of the project also changes.

Event agenda:

1. Why IT contracts do not fit into classic contractual structures.

2. The mixed nature of an IT contract: services, works, licences, copyright, personal data and infrastructure.
3. Technical specification, Agile/Waterfall, sprints and recording changes.
4. Change management: communication channels, authorised persons, response times, follow-up and digital confirmations.
5. Acceptance of works: interim stages, testing, certificates of completed works, digital space and preservation of the digital trail.
6. Rights to software: source code, exclusive rights, background/foreground IP, employee-created works, contractors and open source.
7. SaaS and SLA: service availability, response time, external failures, B2B/B2C offers and subscriptions.
8. Specific features of IT disputes: the intangible nature of the result, complex expert analysis, involvement of the technical team and translation of technical language for the court.
9. Evidence in IT disputes: signed documents, correspondence, Jira, messengers, public sources, digital traces and cyber incidents.
10. Pre-trial settlement and dispute management: technical expert analysis, a commission, an independent expert, continued support in the event of vendor lock-in and the cost of court/arbitration proceedings.
11. Separate questions from the audience: smart contracts, foreign courts and arbitration, and liability for artificial intelligence systems.
12. The discussion was practical: from the structure of the technical specification and acceptance of works to source code, open source components, SaaS, messengers, technical expert analysis and pre-trial commissions.

Below is the edited version of the discussion in interview format.

Why is a standard services agreement unsuitable for IT development?

Event moderator: In IT, many still try to work under a short services agreement.

Why does this structure not always withstand practical use?

Discussion of the event experts:

— Classic contractual structures were formed for more traditional tasks. IT development is arranged differently: software is created for a specific industry-related task, which means that in each project it is necessary to take into account not only the general terms of the contract, but also the specifics of the business for which the product is being developed. An IT contract always contains many technical elements and, if they are not described, the parties will later have to prove matters that could have been recorded in advance in the text of the contract.

— The main difference of an IT contract is its multi-layered and dynamic nature. In addition to the customer and the contractor, third parties are often involved in the project: for example, the licensor of a CRM system or another technology provider. If the licence is revoked or an external service stops working, the customer may bring claims against the contractor, even though the cause of the failure is not entirely within the contractor’s control.

— A contract for the development of an IT product is a mixed structure. It may include elements of a works contract, services, licensing, copyright, personal data regulation and other blocks. Therefore, a simple solution such as “let us take a services agreement and call it an IT contract” works only until the first serious conflict.

— The problem is also that, at the outset, the business process often looks attractive and large-scale, but the lawyer must turn it into a specific subject matter of the contract. It is precisely at this stage that it becomes clear how difficult it is to describe the future product in such a way that the parties do not later argue about what exactly they meant.

How should the technical specification be described if the project follows Agile and is constantly changing?

Event moderator: One of the most frequent sources of disputes is the technical specification.

How should it be recorded if it inevitably changes during the course of the project?

Discussion of the event experts:

— There are two risks. Either the parties constantly revise a large technical specification, or they leave it unchanged and, at the end, receive a product that no longer corresponds to the original document. A more workable approach is to divide the regulation into two levels: to record the framework and objective of the project in the contract, while specific technical specifications, sprints, stages and acceptance are set out in separate documents agreed as the project progresses.

— It is important to build change management in advance. If, during development, a new integration appears, the scope of work changes or the customer departs from the original technical specification, this must be recorded: through an additional agreement, an appendix, minutes of a technical meeting or another instrument agreed in advance. A chronology of events is needed, from which it will later be clear what exactly changed, who approved it and how it affected the timeline or budget.

— The clearer and more structured the technical specification, the less room there is for a future dispute. However, IT practice does not always fit the classic waterfall model: projects involve Jira, sprints, correspondence and arrangements made “as things progress”. The problem begins when the contract does not say a word about Jira being a working channel for recording tasks, while in a dispute the parties try to prove that material changes were agreed there.

What should be included in change management: channels, people and the consequences of silence

Event moderator: How can change management be made non-bureaucratic, but still evidentially reliable?

Discussion of the event experts:

— Not all changes need to be formalised by additional agreements. However, material changes — the subject matter, price and key deadlines — are best recorded in writing. Technical issues may be placed in Jira, Asana, email or other project management tools, provided that the contract expressly states that this is an agreed communication channel.

Returning to the discussion of the experts:

— Digital confirmations must be treated with caution. A push notification or a “confirm” button may be a convenient tool, but this micro-action is not always perceived by an employee as a legally significant decision. If, under the contract, such a button means approval of a change, this may become a serious risk for the customer.

A simpler mechanism was also mentioned from the participants’ practice: after a meeting, sending a follow-up with a recording, link, minutes of the arrangements and a deadline for objections. If the parties have agreed in advance that the absence of a response is deemed to constitute consent, such a tool helps to record the project history without constant additional agreements.

Acceptance: why one should not wait for the final certificate

Event moderator: How are change management and acceptance connected?

Discussion of the event experts:

— Acceptance should not be postponed until the project is fully completed. Clear acceptance stages should be established in advance, interim results should be recorded, authorised persons should be determined and testing results should be preserved. If a dispute arises later, interim acceptance will make it possible to “rewind” and understand at which stage the parties were still on the same page.

In IT, not every test, demonstration or interim result must be closed by a classic certificate of completed works. However, the digital record must be correct, understandable and preserved. For this purpose, the experts proposed using a single digital space for the project — a space where interim results, tests, minutes, access details and other traces of performance are stored.

Event moderator: Accounting is also important in this matter. If the project is divided into stages, part of the results may be closed with primary accounting documents, while interim technical results may be recorded differently.

However, this mechanism must be understood not only by the lawyers and developers, but also by the accountants of both parties.

Source code, rights and open source: code alone does not confer rights

Event moderator: In IT disputes, the following question often arises: if the customer has received the development result,

can it demand the source code?

Discussion of the event experts:

— It is important to distinguish between background IP and foreground IP. Background IP means the developer’s frameworks, libraries and tools that it uses from project to project and does not wish to transfer to the customer. A broad licence may be granted for them.

Foreground IP is what is created specifically for the customer; this is where the customer should acquire exclusive rights, if the parties have so agreed.

A separate risk is the chain of rights. If the product is created by an internal team, employee-created works must be properly documented: the employment contract, job description, specific employer assignment and certificate of acceptance of the result. If contractors are engaged, proper IP clauses are needed in the contracts. If open source is used, the cleanliness of the components must be checked. Otherwise, the problem may be discovered not at acceptance, but several years later, for example during investment due diligence.

It is also important for the customer to establish infrastructure issues in advance: who owns the GitHub repository, whose account is used to purchase the server, where access credentials are stored and who controls the environment. Otherwise, even having the source code may not make it possible to transfer the project to another team without additional costs.

SaaS, SLA and subscriptions: disputes arise not only in custom development

Event moderator: If the product is not developed specifically for the customer, but is provided as SaaS, are there fewer risks?

The experts noted that SaaS reduces some risks, but creates others. In long-term relationships, the SLA must be defined in advance: availability time, response time, the procedure for responding to incidents, support request channels, consequences of exceeding the agreed indicators and allocation of the causes of failure.

If the problem arose because of a provider, backbone network, acquiring bank or another external participant, this is one area of responsibility. If the failure is connected with the developers or the infrastructure of the SaaS provider itself, this is another.

Therefore, the SLA should not merely promise “operability”, but should distinguish what the provider is responsible for and what falls within external factors.

In public B2C and B2B offers, the experts recommended looking not only at the business model, but also at the applicable regulation. It is important to understand what the service is selling: a service or access to a service. The logic of refunding subscription payments may depend on this, especially if the user did not cancel the subscription or claims that they did not actually use the service.

How do IT disputes differ from ordinary commercial disputes?

Event moderator: How do IT disputes fundamentally differ from ordinary commercial disputes?

Discussion of the event experts:

— First, these are dynamic contracts.

In a long-term project, technologies may appear during implementation that did not yet exist at the time the contract was signed.

Second, an IT transaction is often not bilateral: it may involve third and fourth parties that own technologies or licences without which the product does not work.

Third, the result of IT development cannot be “touched” — it must be measured using special tools, the digital trail must be recorded and the technical picture must be explained to the court in ordinary language.

— In IT disputes, technical expert analysis is almost guaranteed to arise. These are disputes with a large volume of evidence and a complex evidentiary process, especially where the judge is not an IT specialist.

— Unlike the supply of goods, it is difficult here to determine how well the result was performed. By the time of the expert analysis, the product may have changed, access to the CRM may have been lost and the licence may have been revoked. As a result, the expert does not always see the same product that was transferred to the customer.

The experts also emphasised that, in an IT dispute, lawyers cannot work separately from the client’s team. Developers, technical specialists and project managers are needed — people who can explain at which stage the malfunction arose, who made the decision and what was actually done.

What evidence works in IT disputes?

Event moderator: If we leave aside the obvious documents, what else may become evidence?

Opinion of the event moderator:

The first thing any dispute still comes down to is an official signed document: a contract, certificate, letter, minutes or incoming reference number. Even when considering a complex IT conflict, the court often begins with familiar questions: where is the certificate, where is the correspondence, was a letter sent, and who received it and when.

However, IT disputes require a broader evidentiary base. In one case, the work was proved through a public presentation of the product: there was no formal final transfer certificate, but the product was presented publicly, reflected in the media and compared with the correspondence and the actual external appearance of the developed solution.

In another case, a cyber incident on a platform that was planned for acquisition was discussed. It was necessary to establish where exactly in the signal transmission chain the problem occurred: in the source code, on the servers, with the platform’s partners or at another point. Ultimately, establishing the technical cause of the incident and the connection between that cause and a defect in the source code became key.

Messengers present a separate difficulty. WhatsApp or Telegram may form part of the evidentiary base if the contract provides in advance that such a communication channel is proper. However, Telegram as an official decision-making channel creates risks: it is difficult to personalise participants, some messages may be deleted and the integrity of the correspondence may later become a matter of dispute.

What should be included in dispute management before a conflict arises?

Event moderator: What dispute resolution mechanisms should be provided for already at the contract stage?

Discussion of the event experts:

— Technical expert analysis may be included in the contract as one of the pre-court stages: it should be determined in advance who will conduct it and what issues it will help clarify. Such expert analysis translates the dispute from technical language into language that is more understandable for the court and the parties.

— It is important to have protocols that record who makes changes, who has access to passwords and who tracks digital traces. This is not only a cybersecurity issue, but also a matter of non-interference, preservation of evidence and the ability to establish the technical cause of the dispute. The pre-trial procedure should make it possible to record the “point of dispute” before each party begins to build its legal argument.

The experts also discussed a commission-based mechanism: the contract may provide for a pre-trial commission with representatives of both parties and, if necessary, an independent technical expert. Such an expert may record the state of the system, while the commission may consider the situation on the basis of that record.

---

One of the event experts drew attention to vendor lock-in: if the customer is technically dependent on the vendor, the dispute should not automatically stop support for the functioning system. The contract may provide that, even in the event of a conflict, the vendor continues support and the customer continues to pay for it in the agreed manner.

The final conclusion of the discussion: a good contract does not guarantee that the parties will never fall out.

---

For cooperation and proposals — PR_revera@revera.legal.

For consultations — kazakhstan@revera.legal.