Software development: The new concept of defects according to §§ 327 ff. BGB

On January 1, 2022, the German legislator fundamentally reformed the regulations for consumer contracts for digital products. For software developers and providers of digital content – from computer games and apps to SaaS services – the newly defined concept of defects is particularly relevant. In this article, we take a detailed look at what is considered to be contractual or defective performance and what rights consumers have since then. The article is aimed at developers, game studios, start-ups and SaaS providers and uses typical scenarios (early access games, cloud services, plugins, etc.) to show where pitfalls lurk. This article follows on from our previous blog post on the legal risks of long development times for crowd-funded games, without repeating its content. Now it is about the practical effects of Sections 327 et seq. BGB on software development – and why legally sound contract drafting is more important than ever.

Contractual conformity: subjective and objective requirements

The new regulations define when a digital product is in conformity with the contract (i.e. free of defects). Three criteria are decisive: subjective requirements, objective requirements and – if relevant – integration requirements. In simple terms, software must fulfill everything that was contractually agreed and also comply with the usual standard of comparable products, unless otherwise effectively agreed.

Subjective requirements are all those properties that have been individually agreed in the contract. These include, in particular, the agreed quality (e.g. certain features, performance parameters, versions), functionality and compatibility with certain systems, interoperability with other software and, if applicable, a use required under the contract. This also includes the provision of accessories, instructions or customer service, if this has been agreed. Even promised updates become part of the subjective requirements – if the provider fails to deliver contractually agreed updates or upgrades, for example, this constitutes a defect. In short, everything you promise the customer in terms of features or services defines the target state from the customer’s perspective.

The software must also fulfill objective requirements, unless expressly agreed otherwise. This refers to the usual purpose of use and the usual quality: the digital product must be suitable for the usual use (e.g. a game must always be playable, a SaaS application must always fulfill the promised functions). It must also have a quality that is usual for digital products of the same type and that the consumer can expect. This includes features such as functionality, continuity of service, compatibility, accessibility and security that are standard for comparable products. Examples: A computer game should run without unusual crashes and meet common performance expectations; an app should meet common data protection and security standards; a cloud service should typically have a certain level of availability (uptime).

It is also objectively required that the software corresponds to the quality of a test version or demo if the consumer was shown one in advance. This means that anyone presenting a beta version or trailer before the contract is concluded must at least fulfill the promises made in the finished product. The software must also be supplied with such accessories and instructions as the consumer may reasonably expect – e.g. installation instructions or a manual, if this is usual for similar products. In addition, unless otherwise agreed, the latest version of the software must be provided upon conclusion of the contract. Delivering an outdated build even though updates are already available would therefore objectively be a defect.

Public statements made by the manufacturer or sales partner are particularly explosive: advertising, product descriptions or announcements can help determine the objectively expectable quality. Consumers may rely on publicly made promises – unless the provider has clearly corrected the statement before purchase or could not have been aware of it. For developers, this means that marketing promises cannot simply be dismissed later as “non-binding previews”; they set the standard by which the product is measured.

Deviations from the objective requirements are possible, but only under strict conditions. According to Section 327h of the German Civil Code (BGB), the consumer must be expressly informed before the contract is concluded that a certain feature of the software deviates from the objective expectations and must expressly agree to this deviation. In practical terms, this means that if, for example, you are selling an early access game that does not meet the usual quality standard of a full-price title or an app with limited compatibility, you must inform the customer of this in no uncertain terms before the purchase – and ideally obtain express confirmation (e.g. by actively setting a checkbox). Otherwise, you cannot simply exclude all warranty claims in the small print. The statutory minimum standards can only be lowered in this way and to a limited extent, but not completely overridden.

Integration requirements play a role if the software has to be installed or integrated into the consumer’s environment by the consumer himself (e.g. a plug-in that the customer integrates into his system). Section 327e BGB states here: The software is in accordance with the contract if the integration has been carried out properly. If the installation is carried out by the provider, the provider is of course liable for correct implementation. If the consumer carries out the installation himself, it is important that no errors on the part of the provider impede the integration. If the integration is improper, there is still no defect, provided that this impropriety is not due to an error in the instructions provided by the trader. In other words: If the software does not run only because the installation instructions provided were incomplete or misleading, the provider remains responsible. If, on the other hand, the customer did not follow the clear instructions or did something wrong on his own authority, the supplier can claim that the product itself is free of defects.

In summary, a digital product is free of defects if it fulfills both the subjective and objective requirements (and has been correctly integrated). If one of these requirements is not met, there is a defect that triggers the consumer’s warranty rights. This comprehensive definition of the target/actual comparison is new and much more specific than previous regulations – especially for software, which was previously often considered outside of traditional sales law.

Update obligations: Updates as part of freedom from defects

One of the most important changes is the legal obligation to provide updates. Digital products are only considered to be free of defects if the necessary updates are provided. This includes functional updates as well as security updates. The background to this is that software is in an ongoing digital environment: Operating systems change, security vulnerabilities emerge, usage requirements evolve. Legislation therefore requires providers to ensure that the software remains “up to date” for a certain period of time.

According to Section 327f BGB, the trader must provide all updates that are necessary to maintain conformity with the contract and inform the consumer about them. Security updates are explicitly mentioned. For example, if a provider fails to patch a known critical bug or security vulnerability, the product could be considered defective because it no longer offers the objectively required security. The same applies if an app no longer runs after an iOS/Android update and no fix is provided – it then no longer complies with the agreed or expected compatibility.

How long does it have to be updated? The law refers to the “relevant period”. In the case of permanent provision – i.e. contracts that run over time, such as SaaS subscriptions or MMO games – this is the entire term of the contract. In the case of one-off provision (e.g. purchase of a software version), it is the period that the consumer can expect based on the type and purpose of the software and the circumstances. What exactly “may expect” is a question of individual cases: in the case of a computer game for €5, buyers may expect only a few months of bug fix support; in the case of expensive licensed professional software, on the other hand, they may expect updates for several years. The legislator deliberately wanted to remain flexible – it depends on consumer expectations.

In practice, this means for developers that the obligation to be free of defects does not end with the delivery of version 1.0. They are still obliged to make improvements in the form of updates for a certain period of time. De facto, the obligation to update is ultimately extended indefinitely, comments a specialist article – because it is unclear exactly when the expectation ends. In particular, retailers who sell third-party software face challenges here: They must contractually ensure that the manufacturer provides sufficient updates, because otherwise the end customer will stick with the vendor. For plug-in developers or app studios, this means planning their business model in such a way that updates (especially security-related updates) can be provided for at least the usual period of use. Otherwise there is a risk of claims for defects, even if the product was initially error-free.

An important point: If the consumer fails to install a provided update even though the provider has pointed this out and correct installation instructions have been supplied, the provider is not liable for any resulting defects. This protective clause relieves the developer if the user ignores updates. Communication should therefore clearly and verifiably point out updates and consequences (e.g. message in the app “Please install update XY, otherwise security risk…”). Any problems that occur later can then be attributed to user behavior.

Subsequent performance: right to bug fixes

If a defect occurs, the consumer initially has the right to supplementary performance (Section 327l BGB). Subsequent performance means that the provider subsequently restores the software to the contractual condition – i.e. removes bugs or supplies missing components. We are familiar with this principle from sales law (repair or replacement delivery) and contract law (rectification of defects), adapted to digital content.

Important: The consumer does not have the right to choose between “repair” and “replacement” in the traditional sense. In the case of software, subsequent performance usually amounts to a patch, an update or a workaround. It is up to the provider to decide how to restore the contractual condition – the main thing is that the defect is rectified. For example, the developer can publish a hotfix or – if this is more efficient – offer the user a replacement in the form of equivalent software. The decisive factor is the result: the software must subsequently meet the requirements.

Subsequent performance must be free of charge for the consumer and must be swift. The law requires the defect to be rectified within a reasonable period of time from the notification of the defect. What is “reasonable” depends on the type of defect and the software. A critical security bug in a SaaS platform, for example, must be fixed very quickly (hours or a few days), whereas a slightly longer update interval may be tolerable for a minor display error in a game. In any case, there must be no significant inconvenience for the consumer – waiting weeks for an essential bug fix, for example, would be unreasonable.

Of course, there may be situations in which subsequent performance fails or would be disproportionate. § Section 327l (2) BGB excludes the claim for subsequent performance if it would only be possible to restore conformity with the contract at disproportionate cost. This should rarely apply (software bug fixes are rarely “disproportionately expensive”), but could be relevant, for example, if a feature is missing that would be extremely costly to implement retrospectively compared to the benefits. In addition, the claim does not apply if subsequent performance is impossible (Section 327l (3) in conjunction with Section 275 BGB). In the case of pure software, “impossible” can actually only mean legal or physical impossibility – for example, if a promised license material cannot be procured after all or a promised online function cannot be provided due to a lack of server infrastructure. In such cases, you jump directly to the other rights (termination of contract, reduction).

As a developer, you should take requests for supplementary performance seriously and fulfill them quickly to avoid slipping into the next stages of the warranty. Customers are legally required to first give the provider this opportunity to rectify the error – it is then up to the provider to justify their trust by acting promptly.

Termination of contract and reduction

If the supplementary performance fails or is exceptionally unreasonable, the consumer may draw more drastic consequences: He can terminate the contract (roughly equivalent to withdrawal) or reduce the price. These rights correspond to the familiar warranty rights in sales law, but are specifically tailored to digital products in Sections 327m and 327n of the German Civil Code (BGB).

Termination of contract (Section 327m BGB): Para. 1 of the standard lists several cases in which the consumer may terminate (end) the contract:

• Impossibility of subsequent performance: If it is clear from the outset that rectification is not possible (e.g. a missing game level cannot technically be supplied because the resources are lacking), the customer can withdraw from the contract immediately.
• Failure to remedy the defect within a reasonable period: If the provider does not respond to the defect report or fails to patch it in time, the consumer may also terminate the contract. They therefore do not have to grant the developer endless attempts to fix the problem.
• Recurrence of a defect despite subsequent performance: If the same defect reappears after an initially successful remedy or if a new defect occurs that shows that the product is not in order after all, the customer can also pull the ripcord. Example: A patch fixes a critical bug, but a few days later similar crashes occur again – this signals that the software is not stable overall.
• Serious defect without waiting: In blatant cases, the consumer may terminate the contract immediately, even without first having to demand rectification. This requires a defect that fundamentally undermines trust. A frequently cited example is an antivirus program that is itself infected with viruses. In this case, it would be unreasonable to expect the customer to wait for repairs – the damage and loss of trust are so serious that immediate withdrawal is justified.

Paragraph 2 of Section 327m also restricts this: In the case of insignificant defects, there is no right to terminate the contract. A minor deviation in appearance or a barely noticeable defect therefore does not entitle the buyer to withdraw from the contract. However, the threshold of “insignificant” is likely to be rather high – in case of doubt, a significant defect is more likely to be assumed if it impairs typical use or relates to a warranty.

Reduction (§ 327n BGB): Instead of terminating the contract completely, the consumer can also reduce the price appropriately. However, this right only exists if a price is actually paid – in the case of purely free offers (in return for data), a reduction is pointless, as only termination of the contract would come into consideration. The reduction practically replaces the withdrawal if the customer wants to keep the software despite the defect. If he declares the reduction, he keeps the digital product, but receives a part of the payment back. The calculation is usually based on a percentage of the reduction in value caused by the defect (similar to sales law). Example: If a SaaS service for €100 per month only delivers half of the promised features, the customer could reduce the price to €50 per month, for example.

Please note: In the case of long-term services (subscriptions), a reduction is equivalent to a future price reduction, whereas a one-off service (purchase price) is more likely to result in a partial repayment. Legally, however, it amounts to the same thing – the consumer pays less because he has received less than agreed.

Compensation: Irrespective of withdrawal or reduction, compensation can also be claimed in certain cases (regulated in Section 327m (3) BGB in conjunction with Section 280 BGB). However, this presupposes that the provider is at fault. It is important for developers that if a defect affects many users, for example, and they suffer consequential damage as a result (e.g. downtime, data loss), this can be expensive. However, liability can often be contractually limited (e.g. through limitations of liability in general terms and conditions, provided these are effective and do not undermine the core obligations).

Practical tip: Most consumers will first try to get a fix (because they want to use the software). If this fails, an amicable solution is often better from the developer’s point of view than resorting to a withdrawal or legal dispute. For example, you can offer a voucher, an extension of the subscription period or a free upgrade – all of which can in fact be equivalent to a reduction in price without any formal legal remedies being exercised. It is only important to seek dialog with dissatisfied customers before they exercise their rights.

Compensation and reversal

If the contract is terminated (withdrawal), the question arises: does the consumer have to pay compensation for the value of the software already used? Under the old law, there were complex rules on when a consumer had to pay for the use of a defective product when withdrawing from a sales contract. For digital products, the legislator has taken a clear position: If the contract is terminated due to a defect, no compensation for use may be imposed on the consumer. Art. 17 para. 3 of the EU Digital Content Directive stipulates that the consumer does not have to pay anything for the service already provided in the event of a warranty claim – this prohibition on compensation for use has been implemented in Section 327o of the German Civil Code (BGB).

In practice, this means that the provider must refund the entire price paid if the consumer has already paid for the service. In return, the consumer must refrain from further use – after all, he gets his money back, so he cannot simply continue to use the digital product. As digital goods cannot be “returned” in the same way as an item, Section 327o of the German Civil Code (BGB) contains the obligation of the consumer to delete the software from their devices and prevent access to it (or close an account, for example). In fact, the entrepreneur bears the full risk: he cannot demand compensation for wear and tear, as is the case with tangible goods.

A special rule applies to permanent services (subscriptions, ongoing services): the provider’s entitlement to remuneration expires for the period in which the digital product was defective. If, for example, an online service was not in accordance with the contract for two out of twelve months due to a defect, the claim for payment lapses. If the customer has already paid in advance, the corresponding pro rata amount must be refunded (i.e. 2/12 of the annual fee in the example). Of course, the provider may no longer charge for services that are no longer to be provided in the future (after the withdrawal). The bottom line is that the consumer gets money back for any defective or unused service periods and the contract is terminated.

An important difference to the right of withdrawal (which can be excluded for digital content under certain circumstances): Here we are talking about warranty rights. The exclusion of compensation therefore applies in the event of a defect. If there is no defect and the consumer wishes to terminate the contract as normal (in the case of continuing obligations) or revoke it (in the case of distance selling, if it has not expired), the general rules apply. In the case of a warranty, however, the consumer should not have to pay any “penalty” for using a defective product – the full incentive lies with the trader to deliver a defect-free product.

For developers, this means that withdrawals can be expensive. Not only do you lose out on sales, you also have no compensation for the fact that the customer may have used the software for weeks or months. You should take this risk into account, especially if you offer a service with an annual subscription, for example – if the customer cancels the contract after 10 months due to a defect, you may have to pay back 10 months of fees. In addition, the provider may have claims under Section 327p BGB to delete the consumer’s digital environment or prevent further use, but this is more theoretical – in practice, you will have to trust the customer to act fairly or provide technical protective measures (e.g. blocking account access).

Scope of application and old contracts (contract before 2022, benefit from 2022)

The rules described apply only in the B2C area, i.e. for contracts between traders and consumers. A “digital product” in this sense is any digital content or service that is made available to the consumer against payment (or against the provision of personal data). This includes software purchase agreements, license agreements, SaaS subscriptions, app purchases, game downloads, cloud storage services and much more. Important: Even if no money is paid, but the consumer provides their data in return, for example (freemium models, “free” apps in exchange for data usage), this is considered a price within the meaning of the law and triggers Sections 327 et seq. This is intended to prevent circumvention – the consumer should also enjoy warranty protection when “paying” with data.

Pure B2B contracts (between companies) are not covered by these regulations. There, what is agreed in the contract continues to apply, as well as the general contract law and, if applicable, the law on defects under sales law (Sections 433 et seq. BGB) or the law on contracts for work and services, but without the special consumer protection features. Nevertheless, the new terms can also serve as a guide in B2B transactions – many manufacturers will (have to) generally adapt their product descriptions in order to meet consumer requirements.

A special feature is the treatment of goods with digital elements (e.g. a smart TV, a car with software). In this case, the core provisions of sales law apply (implemented by the Sale of Goods Directive), but many principles overlap with digital products. In such cases, the law refers in part to Sections 327 et seq. BGB or vice versa. For software developers in the narrower sense (who offer pure software/services), however, it is sufficient to focus on Sections 327 et seq.

Transitional provisions: What about contracts that were concluded before January 1, 2022, but whose service is only provided after the cut-off date? Here, the legislator has created a non-genuine retroactive effect in favor of consumers. According to Art. 229 § 57 EGBGB , the new provisions also apply in principle to old contracts if the digital product is provided from January 1, 2022. A typical example: A video game was sold by pre-order in December 2021, but is not released until 2022 – the game must then comply with Sections 327 et seq. even though the contract was concluded in 2021. The same applies to a SaaS contract from the end of 2021 whose usage phase falls in 2022.

However, there are exceptions: The provisions on changes to digital products (Section 327r BGB) and on entrepreneurial recourse (Sections 327t, 327u BGB) only apply to contracts from 2022 onwards. This mainly concerns the possibility of making subsequent contractual changes to software (feature changes, etc.) – in the case of old contracts, such changes must be resolved differently. However, the core provisions on the concept of defects, subsequent performance, rescission/reduction and updates also apply to old contracts with performance from 2022. For developers in practice, this means that even if you concluded contracts (e.g. license agreements, early access purchases) before 2022, customers who only receive the delivery/service now can assert the new rights. A developer cannot claim that the old law (applicable until 2021) applies to such a customer – if the service is provided now, it must meet the new standards.

Typical problem areas from practice

After this theoretical overview, we will take a look at typical application scenarios and risks for developers:

Early access games: Many game studios release games in early development phases (alpha/beta) as “early access” in order to obtain feedback and secure funding. Legally, an early access title is a digital product that has deliberately not yet been completed. Without special precautions, such an unfinished game would be objectively defective because it does not have the usual characteristics of a finished game (bugs, missing content, balancing problems, etc.). Developers must therefore make it clear that it is an unfinished version. In practice, this is done by means of corresponding notices on platforms such as Steam – the game is explicitly declared as “Early Access”. This declaration can be understood as a quality agreement to the effect that the buyer is not receiving a completed game, but one in the development stage. This shifts the consumer’s expectations: they cannot make any higher demands than is usual for early access titles – the fact that errors and shortcomings occur is then “contractually included”. Attention: However, the mere designation “Early Access” does not release you from all obligations. If the studio promises certain later content or a release schedule in the early access contract, these promises remain subjective requirements. If they are not kept (e.g. the final features are never delivered), this constitutes a defect. In our previous article on crowdfunding projects, we have already emphasized that a game that deviates significantly from what was promised or is not delivered at all can trigger warranty rights. The same applies to early access: transparency about the unfinished state only protects against unjustified expectations, but not against having to fulfill the promises made.

SaaS products and cloud services: In the case of software-as-a-service (such as web platforms, hosted software, subscription model), the provider owes a permanent, contractual service over time. The update and continuity obligations apply here in particular. Downtime or longer service disruptions (e.g. significantly reduced speed, missing functions) can be considered a defect if they go beyond the contractually tolerated level. An SLA (Service Level Agreement), which provides for certain downtimes, defines the scope of the subjective requirements in this respect. If this framework is exceeded – for example, if the service is significantly less reliable than promised – claims for supplementary performance come into play. The provider must therefore establish stable operation as quickly as possible. If this does not succeed, customers may terminate the contract in accordance with Section 327m BGB. Thanks to Section 327o BGB, customers can even demand a refund of part of their fees if the service has not worked as promised for months. Example: A cloud storage service promises 99% uptime, but has regular outages of several hours a day for two months – consumers could argue that the service is defective, demand supplementary performance (stabilization) and terminate the contract if it fails. They would then not have to pay for the downtime or would get their money back. SaaS providers must also guarantee the security of their applications. An unpatched security bug that causes data to be lost is not only a security incident, but also a defect from a civil law perspective (breach of the objective requirement of “security”). In addition to warranty rights, there is also the threat of liability claims.

Another aspect of SaaS is the modification of services in the current contract – regulated in Section 327r BGB. Many SaaS providers are constantly developing their product, but also sometimes remove features from the network or change the scope. The new rules only allow contract changes to the detriment of the consumer under strict conditions (e.g. if the contract provides for this, the change is made for objective reasons and the customer is notified and, if applicable, has a right of termination). Planned feature removals or changes should therefore be checked legally so as not to violate the update and change rules. Otherwise, the customer could also terminate the contract in the event of a significant deterioration and refuse compensation.

Mobile apps and plugins: The new rules apply 1:1 to mobile apps. Even a €0.99 app in the App Store must offer the agreed and usually expected functionality. If it does not – e.g. frequent crashes, non-functioning on an officially supported device – the buyer is entitled to warranty rights. In practice, many consumers are more likely to leave a bad review than take legal action, but the rights still apply in the background. App developers should take care to adhere to compatibility specifications (such as “requires Android 10 or higher”) and provide updates when new OS versions are released. If an app remains non-functional after an iOS update, for example, and the developer does not release an update, this could be considered a defect, as the consumer was entitled to expect compatibility for a certain period of time. The same applies to plugins (e.g. WordPress plugins, browser extensions): Integration also comes into play here. A plugin must always work with the intended main software (WordPress, browser X). If this is not the case and it is due to the plugin (and not due to incorrect installation by the user), the developer is liable. In addition, the user expects the plugin to at least keep pace with the usual updates of the main software – at least for a certain period of time. Anyone selling a WordPress plugin should ideally state which WP versions it has been tested for and approximately how long updates will be offered. If a break occurs (e.g. WordPress 6 is released and the plugin is not adapted), the user could argue that the plugin no longer meets the objective requirements because there is a lack of compatibility and continuity. This is where the reasonable contractual expectation comes into play: With plugins, updates are expected at least across multiple major versions of WordPress – unless it’s clearly declared as “for version X, no guarantee for future” (the deviation agreement issue again!). For developers, this means either clearly defining/limiting what the purchase includes (e.g. “incl. updates for 1 year”) – or expecting customers to consider longer-term support to be owed.

Promises in advertising and crowdfunding: A key risk that the new rules exacerbate is well-meaning but careless promises. Marketing departments and developers tend to want to present their software in the best possible light – “Feature X is coming soon, feature Y is revolutionary, our product can do everything and more!”. Under §§ 327 ff. BGB, such statements can be legally binding statements of quality. Roadmaps are often published, especially in crowdfunding campaigns or early access descriptions. If specific functions or content are announced there (“This game will include a multiplayer mode” or “All backers will receive DLCs for free”), these announcements become part of the subjective requirements. If the multiplayer does not materialize or if the DLC is subject to a charge, this constitutes a breach of contract. Consumers could demand supplementary performance (subsequent installation of the multiplayer) – which is often impossible – and then withdraw from the contract. The consequences are repayments and loss of trust.

The new rules also emphasize that public statements by third parties (e.g. the developer to the publisher, or influencers with official info) can raise expectations. Although the developer is not liable for completely exaggerated advertising statements made by an independent third party, as soon as the developer or publisher itself has initiated such statements, it must be measured against them. Best practice should therefore be: Always coordinate marketing promises with the development department and the legal department. Anything that cannot be delivered with certainty should either not be promised or should only be formulated with reservations. For example, instead of “will have feature X”, say “is planned to add feature X”. However, beware: “planned” can also be interpreted by a consumer as an expectation. It is safer to document exactly what is to be included in the contract (e.g. in the product description/terms and conditions) and what is not. In case of doubt, the provider could regard what is not stated there as not promised – but as mentioned above, public information is included. There is therefore a fine line between honest marketing and legally overloaded disclaimer texts.

One thing is clear: Clumsy liability or warranty exclusions in general terms and conditions are of little help. A developer cannot say “Purchased as seen, no guarantee for any properties” in the general terms and conditions, at least not in consumer transactions. Such clauses would be ineffective because they undermine the minimum statutory rights of consumers. It is better to regulate specifically what is and what is not included in the contract instead of excluding all liability across the board. Mandatory consumer law provisions – such as §§ 327 ff. – cannot be waived anyway.

Conclusion: Recommendations for developers and providers

The new provisions of Sections 327 et seq. BGB significantly strengthen consumer rights for software, games and digital services. For developers, game studios, start-ups and SaaS providers, this means an increased risk of being held liable if products do not have the agreed or objectively expected quality. There is a risk of refund claims, contract terminations or even compensation if, for example, a game falls short of what was promised or a service fails to deliver the promised performance. At the same time, the administrative burden increases, e.g. to fulfill update obligations and ensure support over longer periods of time.

Careful contract drafting is essential to minimize these risks. All key features of the digital product should be clearly defined – ideally in writing in service descriptions or general terms and conditions. This includes scope and functionalities, system requirements, compatibilities and, if applicable, the duration of support and updates. Otherwise, unclear or missing information will be interpreted to the detriment of the developer in cases of doubt, as the law will be interpreted as fulfilling the usual requirements. Where the product deliberately deviates from the usual expectations (e.g. beta status, limited compatibility), the customer must be expressly informed of this and agree to it. Such deviation agreements should be made clearly – for example, through a highlighted statement by the customer (“I am aware that the software XYZ may still contain errors…”). This is the only way to prove later that the consumer was informed.

No false promises: Marketing and product communication should be closely aligned with actual performance. Only promise what you can deliver. Any public assurance – whether in advertising, on the website or in social media – can be legally binding. If in doubt, it’s better to be cautious and refer to future features as a vision rather than a guaranteed promise. Internally, marketing and development should work hand in hand to manage expectations. It also doesn’t hurt to seek legal advice before publishing large-scale promises (e.g. in Kickstarter campaigns).

General terms and conditions and terms of use should be checked by specialized lawyers and adapted to the new legal situation. Clauses that attempt to completely exclude warranty rights or waive the obligation to provide updates are risky and usually ineffective. Instead, you can regulate in the GTC how updates are provided, e.g. that the user has certain obligations to cooperate (install updates, otherwise exclusion of liability in accordance with Section 327f (2) BGB), or how changes are made to an ongoing service (keyword Section 327r BGB). It is also advisable to agree rights of recourse and update commitments in license agreements with suppliers (e.g. if a studio uses an engine or third-party software in its product) so that you yourself are in a position to fulfil your obligations towards end customers.

In view of the complexity of this matter and the sometimes considerable economic consequences (think of mass reversals or loss of reputation due to disappointed users), legal advice is strongly recommended. Fundamental questions should be clarified as early as the development phase: How do we describe our product in a legally compliant way? Which features do we promise in a binding manner and which are better left out? How do we organize beta tests or early access without committing ourselves too much? – A lawyer experienced in IT contract law can provide valuable advice and draw up contract documents that take the new rules of the game into account.

Overall, Sections 327 et seq. BGB show that software and digital content are now legally treated as “real” products that must have certain target characteristics. For software development, this marks a bit of a cultural shift: away from completely free “as is” licensing towards consumer-friendly quality standards. Those who plan for these standards from the outset – both technically and contractually – will ultimately have fewer problems with warranty claims. Clear contracts, realistic promises and proactive support are the key to offering digital products successfully and legally compliant in this new legal framework.