Softwareentwicklung Mängel: §§ 327 BGB & Digitale Produkte | IT-Medienrecht

Erfahren Sie, wie die neuen Regeln zu Softwareentwicklung Mängel nach §§ 327 BGB digitale Produkte betreffen. Vermeiden Sie rechtliche Fallen – jetzt…

Software Development: The New Concept of Defects According to §§ 327 et seq. BGB

On January 1, 2022, the German legislator fundamentally reformed the regulations for consumer contracts involving digital products. For software developers and providers of digital content – ranging from computer games and apps to SaaS services – the newly defined concept of defects is particularly relevant. This article takes a detailed look at what constitutes contractual or defective performance, and what rights consumers have gained since then.

The information is aimed at developers, game studios, startups, and SaaS providers. It uses typical scenarios, such as early access games, cloud services, and plugins, to highlight potential pitfalls. This article builds upon our previous blog post on the legal risks of long development times for crowd-funded games, without repeating its content. Our focus now is on 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, meaning it is 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 upon. It must also comply with the usual standard of comparable products, unless effectively agreed otherwise.

Subjective Requirements

Subjective requirements encompass all properties individually agreed upon in the contract. These primarily include the agreed quality (e.g., certain features, performance parameters, versions), functionality, and compatibility with specific systems. Also included are interoperability with other software and, if applicable, a contractually required use.

This category also covers the provision of accessories, instructions, or customer service, if such provisions were agreed. Furthermore, promised updates become part of the subjective requirements. If the provider fails to deliver contractually agreed updates or upgrades, this constitutes a defect. Essentially, everything you promise the customer regarding features or services defines the target state from the customer's perspective.

Objective Requirements

Unless expressly agreed otherwise, the software must also fulfill objective requirements. This refers to the usual purpose of use and the usual quality. The digital product must be suitable for its usual use; for instance, a game must always be playable, and a SaaS application must always fulfill its promised functions.

The product must possess a quality that is typical for digital products of the same type and that the consumer can reasonably expect. This includes features such as functionality, continuity of service, compatibility, accessibility, and security that are standard for comparable products. For example, a computer game should run without unusual crashes and meet common performance expectations. An app should adhere to common data protection and security standards, and a cloud service should typically maintain 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. Examples include installation instructions or a manual, if these are customary 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 when updates are already available would therefore objectively constitute a defect. Similarly, public statements made by the manufacturer or sales partner are particularly critical. Advertising, product descriptions, or announcements can help determine the objectively expected 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 implies 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. The consumer must then expressly agree to this deviation. In practical terms, if 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 unequivocally before purchase. Ideally, you should obtain express confirmation, for example, by actively checking 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

Integration requirements apply if the software needs to be installed or integrated into the consumer's environment by the consumer themselves. An example is a plugin that the customer integrates into their system. Section 327e BGB states that the software is in accordance with the contract if the integration has been carried out properly. If the installation is performed by the provider, the provider is, of course, liable for correct implementation.

If the consumer carries out the installation, 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 solely because the installation instructions provided were incomplete or misleading, the provider remains responsible. Conversely, if the customer did not follow clear instructions or made an error on their own, 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, a defect exists, triggering 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 often considered outside traditional sales law.

Update Obligations: Updates as Part of Freedom from Defects

One of the most significant changes is the legal obligation to provide updates. Digital products are only considered free of defects if the necessary updates are supplied. This includes both functional and security updates. The rationale behind this is that software operates within a dynamic digital environment: operating systems change, security vulnerabilities emerge, and usage requirements evolve. Consequently, legislation requires providers to ensure that their software remains “up to date” for a certain period.

According to Section 327f BGB, the trader must provide all updates 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 must updates be provided? The law refers to the “relevant period”. For permanent provision—i.e., contracts that run over time, such as SaaS subscriptions or MMO games—this period spans the entire term of the contract. For 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 determined on a case-by-case basis. For a computer game costing €5, buyers might expect only a few months of bug fix support. Conversely, for expensive licensed professional software, updates for several years might be expected. The legislator deliberately aimed for flexibility; 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.

Developers are still obliged to make improvements through updates for a certain period. "De facto, the obligation to update is ultimately extended indefinitely," as one specialist article comments, because it is unclear precisely when the expectation ends. Retailers selling third-party software face particular challenges here. They must contractually ensure that the manufacturer provides sufficient updates, because otherwise the end customer will hold the retailer responsible. For plug-in developers or app studios, this means designing their business model to provide updates, especially security-related ones, 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. This further emphasizes the need for comprehensive contract drafting for SaaS companies.

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 their consequences, such as a message in the app stating: “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 its contractual condition. This involves removing bugs or supplying missing components. This principle is familiar from sales law, specifically regarding repair or replacement delivery, and from contract law concerning rectification of defects, adapted for digital content.

Crucially, the consumer does not have the right to choose between “repair” and “replacement” in the traditional sense. For software, subsequent performance usually involves a patch, an update, or a workaround. It is up to the provider to decide how to restore the contractual condition; the main goal is to rectify the defect. For example, the developer can publish a hotfix or, if more efficient, offer the user a replacement in the form of equivalent software. The decisive factor is the outcome: 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 constitutes “reasonable” depends on the type of defect and the software. A critical security bug in a SaaS platform, for instance, must be fixed very quickly (within hours or a few days). In contrast, a slightly longer update interval may be acceptable 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, situations may arise where subsequent performance fails or would be disproportionate. Section 327l (2) BGB excludes the claim for subsequent performance if restoring conformity with the contract would only be possible at disproportionate cost. This rarely applies, as software bug fixes are seldom “disproportionately expensive.” However, it could be relevant if a missing feature would be extremely costly to implement retrospectively compared to its benefits. Moreover, the claim does not apply if subsequent performance is impossible (Section 327l (3) in conjunction with Section 275 BGB). For pure software, “impossible” typically refers to legal or physical impossibility. This could occur if promised license material cannot be procured after all, or if a promised online function cannot be provided due to a lack of server infrastructure. In such cases, other rights, such as termination of contract or reduction, become applicable.

As a developer, you should take requests for supplementary performance seriously and fulfill them quickly to avoid progressing to the next stages of warranty claims. Customers are legally required to first grant 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 supplementary performance fails or is exceptionally unreasonable, the consumer may take more drastic actions: they 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

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

Paragraph 2 of Section 327m further 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 cases of doubt, a significant defect is more likely to be assumed if it impairs typical use or relates to a warranty.

Price Reduction

Reduction (§ 327n BGB): Instead of completely terminating the contract, the consumer can also reduce the price appropriately. However, this right only applies if a price is actually paid. For purely free offers, such as those exchanged for data, a reduction is pointless, as only contract termination would be relevant. The reduction practically replaces withdrawal if the customer wishes to retain the software despite the defect.

If the consumer declares the reduction, they keep the digital product but receive a portion of the payment back. The calculation is typically based on a percentage of the reduction in value caused by the defect, similar to sales law. For instance, if a SaaS service costing €100 per month only delivers half of its promised features, the customer could reduce the price to €50 per month.

Please note: For long-term services, such as subscriptions, a reduction equates to a future price adjustment. For a one-off service with a purchase price, it is more likely to result in a partial repayment. Legally, however, both amount to the same outcome: the consumer pays less because they have received less than agreed.

Compensation

Irrespective of withdrawal or reduction, compensation can also be claimed in certain cases, as 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 through liability limitations in general terms and conditions, provided these are effective and do not undermine core obligations.

Practical tip: Most consumers will first attempt to obtain a fix because they want to use the software. If this fails, an amicable solution is often preferable from the developer's perspective than resorting to withdrawal or a legal dispute. For example, you can offer a voucher, an extension of the subscription period, or a free upgrade. All of these options can effectively equate to a price reduction without formal legal remedies being exercised. It is crucial to seek dialog with dissatisfied customers before they exercise their rights.

Compensation and Reversal

If a contract is terminated (withdrawal), the question arises: does the consumer have to pay compensation for the value of the software already used? Under older laws, complex rules dictated 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.

Article 17, paragraph 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, they receive their money back, so they cannot simply continue to use the digital product. As digital goods cannot be “returned” in the same way as physical items, Section 327o of the German Civil Code (BGB) includes the obligation for the consumer to delete the software from their devices and prevent access to it, for example, by closing an account. In essence, the entrepreneur bears the full risk. They cannot demand compensation for wear and tear, as is the case with tangible goods.

A special rule applies to permanent services, such as subscriptions or ongoing services: the provider’s entitlement to remuneration expires for the period in which the digital product was defective. For example, if 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, meaning 2/12 of the annual fee in this example. Of course, the provider may no longer charge for services that will not be provided in the future after the withdrawal. Ultimately, the consumer receives money back for any defective or unused service periods, and the contract is terminated.

An important distinction to note is the right of withdrawal, which can be excluded for digital content under certain circumstances. Here, we are discussing warranty rights. Therefore, the exclusion of compensation 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. However, in the case of a warranty claim, 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 implies that withdrawals can be expensive. Not only do you lose sales, but you also receive no compensation for the fact that the customer may have used the software for weeks or months. You should account for this risk, especially when offering services with annual subscriptions. If a customer cancels the contract after 10 months due to a defect, you might have to refund 10 months of fees. Additionally, while the provider may have claims under Section 327p BGB to delete the consumer's digital environment or prevent further use, this is often theoretical. In practice, you will likely need to trust the customer to act fairly or implement technical protective measures, such as blocking account access.

Scope of Application and Old Contracts

The rules described apply only in the B2C area, specifically to contracts between traders and consumers. A “digital product” in this context refers to any digital content or service provided to the consumer against payment or the provision of personal data. This includes software purchase agreements, license agreements, SaaS subscriptions, app purchases, game downloads, and cloud storage services, among others. Crucially, even if no money is exchanged, but the consumer provides their data in return—for example, with freemium models or “free” apps in exchange for data usage—this is considered a price within the meaning of the law and triggers Sections 327 et seq. BGB. This provision aims to prevent circumvention, ensuring that consumers also enjoy warranty protection when “paying” with data.

Pure B2B contracts, those between companies, are not covered by these regulations. For such contracts, the agreed terms continue to apply, along with 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. However, these lack the special consumer protection features. Nevertheless, the new terms can serve as a guide in B2B transactions, as many manufacturers will need to generally adapt their product descriptions to meet consumer requirements. For further insights into compliance requirements in SaaS, refer to our related article.

A special feature is the treatment of goods with digital elements, such as a smart TV or a car with software. In these cases, the core provisions of sales law apply, as implemented by the Sale of Goods Directive. Many principles, however, overlap with digital products. In such scenarios, the law often refers to Sections 327 et seq. BGB or vice versa. For software developers in the narrower sense, who offer pure software or services, focusing on Sections 327 et seq. BGB is sufficient.

Transitional Provisions

Transitional provisions: What about contracts that were concluded before January 1, 2022, but whose service is only provided after this date? 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 involves a video game sold by pre-order in December 2021 but not released until 2022. This game must then comply with Sections 327 et seq. BGB, 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, such as feature changes. For older contracts, such changes must be resolved differently. Nevertheless, the core provisions concerning the concept of defects, subsequent performance, rescission/reduction, and updates also apply to older contracts with performance beginning in 2022. For developers in practice, this means that even if you concluded contracts, such as license agreements or early access purchases, before 2022, customers who only receive the delivery or 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

Following this theoretical overview, let us examine typical application scenarios and risks for developers:

Early Access Games

Many game studios release games in early development phases, such as alpha/beta versions, as “early access” to gather 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 lacks the usual characteristics of a finished game, including bugs, missing content, and balancing issues.

Developers must therefore make it clear that it is an unfinished version. In practice, this is done through corresponding notices on platforms like Steam, where the game is explicitly declared as “Early Access.” This declaration can be understood as a quality agreement, signifying that the buyer is not receiving a completed game, but one in the development stage. This shifts the consumer’s expectations: they cannot make higher demands than what is customary for early access titles. The occurrence of errors and shortcomings is then “contractually included.”

Attention: However, merely labeling a product as “Early Access” does not release you from all obligations. If the studio promises certain future content or a release schedule in the early access contract, these promises remain subjective requirements. If they are not fulfilled, for example, if final features are never delivered, this constitutes a breach of contract. Consumers could demand supplementary performance, such as the subsequent installation of multiplayer functionality, which is often impossible, and then withdraw from the contract. As discussed in our previous article on crowdfunding projects, a game that significantly deviates 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 the obligation to fulfill promises made.

SaaS Products and Cloud Services

For Software-as-a-Service, such as web platforms, hosted software, or subscription models, the provider owes a permanent, contractual service over time. The update and continuity obligations are particularly critical here. Downtime or prolonged service disruptions, such as significantly reduced speed or missing functions, can be considered a defect if they exceed contractually tolerated levels. A Service Level Agreement (SLA), which outlines acceptable downtimes, defines the scope of the subjective requirements in this regard.

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 fails, 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. For instance, if a cloud storage service promises 99% uptime but experiences 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 receive their money back. SaaS providers must also guarantee the security of their applications. An unpatched security bug leading to data loss is not only a security incident but also a civil law defect, as it breaches the objective requirement of “security.” In addition to warranty rights, liability claims may also arise. For insights on managing such risks, consider our article on defectiveness of SaaS solutions.

Another aspect of SaaS is the modification of services within an ongoing contract, as regulated in Section 327r BGB. Many SaaS providers constantly develop their products, but sometimes remove features or change the scope. The new rules only permit contract changes to the detriment of the consumer under strict conditions. These include situations where the contract provides for such changes, the change is made for objective reasons, the customer is notified, and, if applicable, the customer has a right of termination. Therefore, planned feature removals or changes should be legally reviewed to avoid violating update and change regulations. 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 directly to mobile apps. Even a €0.99 app in the App Store must offer the agreed and usually expected functionality. If it fails to do so—e.g., frequent crashes, non-functioning on an officially supported device—the buyer is entitled to warranty rights. While many consumers are more likely to leave a bad review than pursue legal action, these rights still apply. App developers should prioritize adhering 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. The consumer was entitled to expect compatibility for a certain period. The same applies to plugins, such as WordPress plugins or browser extensions. Integration is also a key factor here. A plugin must consistently function with its intended main software (e.g., WordPress, browser X). If this is not the case and the issue lies with the plugin, not improper installation by the user, the developer is liable.

Furthermore, the user expects the plugin to keep pace with the usual updates of the main software, at least for a certain period. 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, for instance, if WordPress 6 is released and the plugin is not adapted, the user could argue that the plugin no longer meets the objective requirements due to a lack of compatibility and continuity. This is where reasonable contractual expectation becomes crucial. For plugins, updates are expected across multiple major versions of WordPress, unless it is clearly declared as “for version X, no guarantee for future” (which is again the deviation agreement issue!). For developers, this means either clearly defining and limiting what the purchase includes, for example, “incl. updates for 1 year,” or preparing for customers to expect longer-term support.

Promises in Advertising and Crowdfunding

A key risk exacerbated by the new rules is well-meaning but careless promises. Marketing departments and developers often wish to present their software in the best possible light, proclaiming: “Feature X is coming soon, feature Y is revolutionary, our product can do everything and more!” Under §§ 327 ff. BGB, such statements can become legally binding statements of quality. Roadmaps are frequently published, especially in crowdfunding campaigns or early access descriptions.

If specific functions or content are announced there, such as “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 mode does not materialize or if the DLC is subsequently charged for, this constitutes a breach of contract. Consumers could demand supplementary performance, such as the subsequent installation of the multiplayer, which is often impossible, and then withdraw from the contract. The consequences include repayments and a loss of trust.

The new rules also emphasize that public statements by third parties, such as a developer speaking to a publisher or influencers with official information, can raise expectations. While a developer is not liable for entirely exaggerated advertising statements made by an independent third party, as soon as the developer or publisher initiates such statements, they 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, be cautious: “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, for instance, in the product description or terms and conditions, and what is not. In case of doubt, the provider could argue that what is not explicitly stated was not promised. Yet, as mentioned earlier, public information is also considered. Therefore, there is a fine line between honest marketing and legally overloaded disclaimer texts. Our article on common legal mistakes for startups offers further guidance.

One thing is clear: clumsy liability or warranty exclusions in general terms and conditions are of little help. A developer cannot state “Purchased as seen, no guarantee for any properties” in their 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, rather than attempting to exclude all liability across the board. Mandatory consumer law provisions, such as §§ 327 ff. BGB, cannot be waived in any case.

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, startups, and SaaS providers, this implies an increased risk of liability if products do not possess the agreed or objectively expected quality. There is a risk of refund claims, contract terminations, or even compensation if, for instance, a game falls short of what was promised or a service fails to deliver the promised performance. Concurrently, the administrative burden increases, for example, to fulfill update obligations and ensure support over longer periods.

Careful contract drafting is essential to minimize these risks. All key features of the digital product should be clearly defined, ideally in writing within 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 presume the fulfillment of usual requirements. Where the product deliberately deviates from usual expectations, such as beta status or 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 from the customer: “I am aware that the software XYZ may still contain errors…” This is the only way to later prove that the consumer was informed. For more on this, consult our resource on legally compliant contract drafting for software development.

Avoid false promises: Marketing and product communication should closely align 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. When in doubt, it is better to be cautious and refer to future features as a vision rather than a guaranteed promise. Internally, marketing and development teams should collaborate closely to manage expectations. Seeking legal advice before publishing large-scale promises, such as in Kickstarter campaigns, is also highly advisable. You might find our discussion on binding effect and design of term sheets for startup investments relevant here.

General terms and conditions and terms of use should be reviewed by specialized lawyers and adapted to the new legal situation. Clauses attempting to completely exclude warranty rights or waive the obligation to provide updates are risky and typically ineffective. Instead, you can regulate in the GTC how updates are provided, for example, by stipulating that the user has certain obligations to cooperate, such as installing updates, failure of which may lead to an exclusion of liability in accordance with Section 327f (2) BGB. You can also define how changes are made to an ongoing service, referencing Section 327r BGB. It is also advisable to agree on rights of recourse and update commitments in license agreements with suppliers. This is crucial if a studio uses an engine or third-party software in its product, ensuring you can fulfill your obligations towards end customers.

In view of the complexity of this matter and the sometimes considerable economic consequences, such as 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 account for the new rules of the game. For more about general legal challenges for startups, refer to our related content.

Overall, Sections 327 et seq. BGB demonstrate that software and digital content are now legally treated as “real” products that must possess certain target characteristics. For software development, this marks a cultural shift: moving 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 encounter fewer problems with warranty claims. Clear contracts, realistic promises, and proactive support are the keys to offering digital products successfully and legally compliant within this new legal framework.