Commitment to Effort or Obligation to Result

An obligation to make an effort or an obligation to achieve results in IT contracts: what should you really pay attention to as a startup?

In many IT contracts, the terms effort obligation and obligation to achieve results appear sooner or later. Suppliers often want to formulate their obligations as lightly as possible. On the contrary, clients want certainty about delivery, quality and timing. This is understandable, especially when a startup depends on software, integrations, hosting or development capacity to scale.

However, the distinction is less simple than it seems at first glance. An obligation to make an effort does not mean that a supplier can work without obligation. Even then, action must be taken professionally and carefully. At the same time, an obligation to achieve results does not automatically mean that you are strong as a client if the intended result is not described sharply enough.

At Startup-Recht, we regularly see that discussions on this subject are in fact not just about legal labels, but mainly about risk sharing. Who bears the risk if a project ends? Who has to prove that insufficient performance has been performed? And what rights does a client have if the end result is left behind?

What is the difference between an effort obligation and an obligation to achieve results?

The classic distinction is essentially quite clear.

In the case of an effort obligation, the performance consists of making sufficient effort. The supplier therefore does not simply promise that a certain result will be achieved, but that he must behave as would be expected from a reasonably acting and competent contractor.

In the case of an obligation to achieve results, a concrete result is actually promised. Then it's not just about whether hard work has been done, but mainly whether the agreed result has actually been achieved.

This difference sounds theoretical, but it has a very practical effect in IT projects. For example, the development of a standard website or the implementation of standard software. If the intended result should simply be achievable under normal circumstances, an obligation to achieve results is more obvious. If it concerns an assignment with many uncertainties, dependencies or influence on the part of the client, an obligation to make an effort is more readily apparent.

It is also important that one agreement often contains several types of obligations. For example, a supplier may have performance obligations regarding availability, delivery or repair of defects, while other parts of the same deal should rather be seen as an effort obligation. That is precisely why a black and white approach is often too crude.

Why one contract rarely consists of effort or just results

In practice, an IT agreement is sometimes generically portrayed as a contract based on effort or results. That seems clear, but usually does not do justice to reality.

Take secondment. This is often seen as a textbook example of an exercise relationship. However, this can include hard result components, such as making a specialist with certain qualifications available in time. Conversely, in software development, an assignment as a whole can feel result-oriented, while certain activities along the way are highly dependent on input, choices and cooperation from the client.

This is an important point for startups and scale-ups. Especially in early growth phases, there is a great temptation to contract mainly at speed. This quickly creates a document containing general definitions and standard clauses, but does not sufficiently specify which obligations are really tough and which are not. This often results in discussion later.

A general provision that all obligations count as best efforts obligations, or, on the contrary, as obligations to achieve results, usually does not solve that problem. Judges ultimately look at the content of the concrete agreement and the circumstances of the case. The label alone is therefore rarely decisive.

The real question: what should you reasonably expect from the supplier?

Whether an obligation should be seen as an effort or result obligation depends essentially on the explanation of the agreement. In addition, not only the literal text is important, but also how the appointment is organized.

A number of factors make an obligation to achieve results more plausible. Think of a concretely defined end result, a fixed scope, a clear deadline, guarantees about the outcome or a price structure where the supplier is financially charged for the end result.

On the other hand, some circumstances are more likely to point towards an obligation to make an effort. For example, when the client has a lot of influence on execution, when capacity or expertise is mainly provided, when a hard deadline is missing, or when terms mainly describe an intended outcome or wish without a real guarantee of results.

For founders and legal teams, this is a useful reality check. Not the chosen term, but how you structure the deal, often determines the legal outcome. A contract can therefore be full of strong language on paper, while the design of the project suggests a lighter obligation. And vice versa, a supplier who calls for an “effort” everywhere can still be held to a concrete result agreement if the scope, planning and financial incentives indicate this.

Proof: This is where the difference really becomes felt

The greatest practical importance of this distinction often lies in the evidence.

In principle, with an obligation to achieve results, the client has a clearer starting point. If the agreed result has not been achieved, it is more likely that there is a shortcoming. The discussion then shifts rather to questions about repair, term, damage or dissolution.

This is more difficult with an obligation to make an effort. Then the client must not only show that the end result is disappointing, but also that the supplier has made insufficient efforts. This is often complicated in IT matters. A large part of the execution takes place within the supplier's organization, out of sight of the client. In addition, the client regularly lacks the technical expertise to properly assess whether a supplier has done enough.

This often makes the supplier's position of proof stronger. Not only has his obligation been worded less harshly, but the client also has a heavier obligation to provide evidence. For many startups, this is an underestimated risk. Anyone who only discovers in the event of a conflict that is not clearly defined what the supplier should have done is quickly behind.

There is something else to add. An obligation to achieve results doesn't help you much either if the result itself is vaguely described. A provision that a supplier must provide “a well-functioning website” provides little guidance if it is not worked out what that website should look like, what functionalities are required, what performance is expected and within what period of time all this must be completed. A result is only legally useful if it has been made sufficiently concrete.

Why SLAs and acceptance procedures are often more important than the label

Many IT contracts lack an explicit qualification as an obligation to make an effort or result. However, these contracts often contain mechanisms that are much more relevant in practice.

A good example is the service level agreement, or SLA. It sets out concrete performance levels, such as the availability of an application or response times in case of incidents. This usually does not mean that the service must be permanently error-free. However, a measurable framework will be created through which performance can be assessed.

Something similar applies to acceptance regulations in software development. In addition, it is often agreed that the client tests upon delivery, reports defects and the supplier has the opportunity to repair them. This also shows that the first delivery does not necessarily have to be perfect. At the same time, this creates a system that ultimately makes it clear whether the required level has been reached.

For startups and scale-ups, these are often the provisions that really matter. Not the abstract discussion about effort or results, but the concrete question: which service levels apply, when is something acceptable, which errors should be resolved within which time frame, and what happens if that fails?

That is precisely where the operational value of a contract lies. A supplier can work on paper with an obligation to do its best, but if the SLA sets hard standards and clear remedies apply if exceeded, the client still has a useful tool. Conversely, a so-called result is of little use if the contract only offers a minimal discount or limited compensation in the event of underperformance.

Generic clauses: attractive on paper, limited in value

Many standard contracts and terms and conditions include a generic rule. For example, that all obligations of the supplier are considered to be best efforts, unless otherwise expressly agreed. Sometimes the opposite also happens.

Such provisions seem useful, but their practical value is limited. An agreement usually consists of a bundle of different obligations. There is seldom one uniform qualification for that. Moreover, the case law shows that judges regularly overrule a generic clause if the concrete structure of the obligation leads to a different conclusion.

That does not mean that such a provision is useless. In some cases, a generic clause can indeed remain in place and thus benefit the party that included it. This can still be strategically relevant, especially in templates or standard terms and conditions.

Yet the most important lesson is another one. If you want real clarity, it's better to see how hard that agreement should be for each core obligation. This is more labour-intensive than including one general rule, but is much more in line with how IT projects actually function.

Where startups and scale-ups can make a difference in contract negotiations

For young tech companies, there is a great temptation to focus primarily on price, speed and going live. Legal qualifications then receive less attention, while they can weigh heavily later. The better negotiation strategy is usually to move the conversation from labels to content.

That starts with a sharp description of what. What exactly needs to be supplied? Which functionalities, links, performance requirements and quality criteria are included?

Then it comes when. When does something need to be ready? Is there a hard deadline or just a target date? What happens if the schedule is not met?

Next, the scope is essential. Is it a fixed project for a fixed price, or capacity on a post-calculation basis? The greater the freedom of choice and influence on the client side, the harder it usually becomes to enforce a hard result afterwards.

Finally, remedies are crucial. What rights does the client have in the event of delays, malfunctions or defective delivery? Is there a recovery obligation? Are there service credits? Is there a right to terminate? And are the consequences of non-performance actually felt by the supplier?

At Startup-Recht, we see that it is precisely these components that often have more value than an abstract debate about whether something is formally an obligation to make an effort or result. Those who make the result concrete, set deadlines properly and organize remedies smartly are usually stronger than those who only bet on a nice legal label.

The core lesson for IT contracts: less semantics, more precision

The discussion about effort obligations and obligations to achieve results remains relevant, precisely because it says something about risk distribution, evidence and enforceability. But those who get too hung up on that often miss what the contract should really focus on.

For clients, an obligation to achieve results is attractive, but only valuable if the result is really concrete, testable and linked to clear consequences. A best-efforts obligation is attractive for suppliers, but it does not offer a license if the agreement, in terms of design and content, strongly points to a hard performance.

The most sensible approach is therefore usually not to endlessly negotiate one generic qualification. It is more useful to clearly determine for each core part of the deal what needs to be delivered, when that should be done, what room there is for recovery, what service levels apply and what remedies are available if things go wrong.

Conclusion

For startups and scale-ups, the distinction between an obligation to make an effort and an obligation to achieve results is certainly relevant, but not because the label determines everything on its own. The real value lies in the elaboration of the obligation: a clear scope, concrete results, clear deadlines and workable remedies.

When concluding an IT contract, it is therefore wise to invest less energy in abstract terminology and more into accurately formulating expectations and consequences. This is where it is determined whether a contract protects your company if the project comes under pressure.

‍