No-Code/Low-Code Contract: Legal Guide | IT-Medienrecht

Protect your No-Code/Low-Code project! Discover essential legal pitfalls to avoid when drafting your No-Code/Low-Code contract for secure software…

No-code and low-code platforms enable rapid software development without extensive manual programming. Applications are increasingly developed using tools such as Bubble, Webflow, Airtable, or Auth0 to save time and costs. However, these modern approaches introduce particular contractual challenges. Clients and developers must recognize that a no-code contract requires drafting just as carefully as a traditional IT contract. Neglecting this can lead to risks like unclear performance obligations, disputes over missing source code, dependencies on third-party platforms, or gaps in usage rights.

The following points highlight crucial aspects to ensure that contracts for no-code/low-code software development are drafted professionally and legally compliant. Our approach is neutral and legally sound, aiming to prevent future conflicts.

Special Contractual Clauses for No-Code/Low-Code Development

When software is created, either in whole or in part, using no-code/low-code tools, contracts should include specific clauses that go beyond standard software agreements. These special clauses address the unique nature of these development methods.

Defining the Scope of Services

First and foremost, it is vital to clearly define the scope of services. What exactly does the developer owe the client? In traditional projects, this often means delivering source code and installable software. However, no-code projects typically lack classic source code. Instead, they involve a configured application on a platform.

Therefore, the contract must explicitly define the end result. This could be, for instance, a functional application on the selected platform, including all workflows, settings, and required access. A clear definition prevents misunderstandings regarding deliverables.

Rights of Use and Ownership

Furthermore, rights of use and ownership must be expressly regulated. The client needs to be granted the right to use the developed no-code application as intended, exclusively if desired. Concurrently, it must be clarified that rights to the no-code platform itself or to prefabricated modules are not transferred.

This means the customer does not acquire ownership of the tool or its standard modules. Instead, they gain rights only to the individually created components of the application. For example, a customer may use and modify content on a website built with Webflow, but does not acquire rights to the Webflow software or its general design templates. Such clauses, though seemingly obvious, are invaluable in preventing disputes. Clear headings like "Rights of Use Software Development" or "Rights to No-Code Components" underscore their importance.

For more detailed information on software ownership, see our article on ownership of software.

Third-Party Providers and Integrations

Regulations concerning third-party providers and integrations form another critical part of the contract. No-code/low-code solutions frequently integrate external services. Examples include payment providers via API, cloud databases, or other SaaS services.

The contract should specify who is responsible for these third-party services and who bears the associated costs. For instance, must the client provide their own licenses or subscriptions for Airtable, Webflow & Co.? Will the client pay fees directly, or will the developer procure accounts and then invoice the client? Such financing and cooperation obligations on the client's part should be explicitly included in the contract, referencing provisions like § 642 BGB on the client's duty to cooperate. It is also important to note that the developer is not responsible for the performance of these external services, unless otherwise agreed.

Example: If a connected email service fails, the developer should not be held liable without verification. For deeper insights into SaaS agreements, consider our article on SaaS contracts.

Practical Tip: Managing Platform Accounts

It is often beneficial for the client to set up their own accounts with the necessary no-code platforms early on. Alternatively, they can grant the developer access to their existing account. This approach allows the client to retain control.

The finished application can then be easily transferred to the client at the contract's conclusion. Contracts should explicitly stipulate that the created application is ultimately transferred to the client's account, or that the client receives full administrator rights. This ensures the customer is not left without access upon termination of the business relationship.

Developer's Duty to Inform about Limits and Risks

A crucial question pertains to the developer's duty to inform the customer about the limitations, risks, and dependencies of third-party platforms. Fundamentally, each contracting party must consider the rights, legal interests, and general interests of the other party (Section 241 (2) BGB).

Within a project context, this creates a duty for the software developer to provide advice and information. The developer cannot remain silent if they realize that certain customer requirements cannot be met with the chosen no-code/low-code solution, or if significant risks exist, such as dependence on a cloud platform. The extent of this advisory duty varies with circumstances, particularly the client's expertise. A technically inexperienced customer requires a more comprehensive warning, while a knowledgeable customer might need less detailed explanations.

Key Information Requirements

Specifically, the developer must inform the client about the main limitations of the no-code tools both before contract conclusion and during implementation. If a desired functionality cannot be implemented with the selected platform, or only through workarounds, the client must be informed promptly. Risks such as scaling limits, including the maximum number of users or data volumes the system can handle, also require disclosure.

The risk of a vendor lock-in, meaning dependence on a single provider, should also be addressed. No-code solutions frequently rely on proprietary systems. Clients should understand that switching platforms later can entail considerable effort. For further details on legal implications, consult our guide on liability when using VibeCoding and no-code platforms.

Practical example: An agency suggests developing a startup's application entirely on a no-code platform for faster delivery. However, the agency knows that the platform does not fully meet certain European data protection requirements, and performance issues could arise with high user volumes. The agency is obligated to inform the client of these points.

Failure to do so could result in liability for damages, perhaps due to a breach of pre-contractual obligations (culpa in contrahendo) or secondary obligations from the contract. In German contract law for work and services, the developer might even be considered partly at fault (§ 254 BGB) if they fail to address recognizable flaws in the client's concept. Therefore, transparency from the outset protects both parties.

Dependencies on Third-Party Providers

Additionally, the duty of disclosure includes references to dependencies on third-party providers. The customer must understand that their fully developed application's stability and availability are intrinsically linked to the underlying platform. If known restrictions exist, such as API limits or a lack of offline options, the developer should clearly communicate these.

If necessary, the developer must also suggest alternatives. For example: "Function X does not work with this no-code tool; a custom development or an additional plugin would be required." This empowers the client to make an informed decision. Ideally, this advice should be documented in writing or explicitly recorded in the contract to prevent future disputes.

Liability for No-Code Platform Failures or Discontinuation

A significant risk in software development with no-code/low-code is the reliance on the availability and stability of the chosen platform. What happens if services like Bubble, Webflow, Airtable, or Auth0 fail, face temporary restrictions, or are discontinued? Contracts must clearly define who bears which risk in such scenarios.

Allocation of Responsibility

Generally, the developer is responsible for the contractually agreed service, such as creating a functional application on the selected platform. However, the developer is usually not responsible for the platform's ongoing operation; this falls to the platform provider.

Therefore, the contract should include a limitation of liability. This clause would exempt the developer from liability for circumstances beyond their control (see Section 276 (1) BGB on liability). For example, a clause could define outages or performance degradation of the underlying SaaS platform as force majeure or other circumstances beyond the developer's influence. This clarifies that such external events do not constitute a breach of contract by the developer.

Example: A business app, developed by a contractor, runs entirely on Airtable. One day, Airtable experiences a major outage or changes its API, causing parts of the app to stop functioning. Without prior arrangements, the client might claim a defect or failure from the developer. A suitable contractual clause, however, would stipulate that the developer is not liable for errors they did not cause. In such cases, it would be an issue for the platform provider's support, or, if agreed, a matter of joint crisis management where the developer assists with troubleshooting for an additional fee.

Dealing with Platform Discontinuation

Beyond technical failures, the complete loss of the platform must also be considered. No-code platforms might change their business models, implement drastic price increases, or even cease operations. In such events, the contract should at least stipulate that a discontinuation constitutes a change in the basis of the business.

If necessary, parties can agree to renegotiate, or the client may have a special termination right if the project's foundation (the available platform) ceases to exist. Typically, the developer cannot guarantee a platform will exist forever or remain unchanged. This entrepreneurial risk is largely borne by the client who chose the no-code route. However, the developer can offer support, such as outlining alternative scenarios like migration to another platform or data export. Understanding the various liability aspects is crucial for both parties, as highlighted in the New EU Product Liability Directive 2023.

Limiting Liability and Warranty

It is always advisable to tailor liability and warranty to the specifics of no-code projects. Traditional software contracts include warranty periods for defects and often broad exclusions for consequential damages. In the no-code context, the warranty should be limited to ensuring the created application functions as per the contract at the time of acceptance.

Subsequent changes or platform failures would not be considered defects in the work performance, but rather environmental changes. The developer's liability can be contractually excluded or limited to cases of intent and gross negligence. However, such limitations of liability must be carefully formulated in general terms and conditions (GTC) to comply with Section 307 BGB. Mandatory liability, such as for personal injury or under product liability law, must remain unaffected, though this rarely applies to pure software. Both parties should meticulously review liability provisions to clarify who bears what damage in an emergency.

Rights Transfer and "Source Code Equivalents"

In conventional software development, the transfer of copyright usage rights to the software is typically agreed upon in the contract, often alongside the handover of the source code to the client. This becomes more complex in the no-code/low-code domain, where a comprehensive source code for handover is often absent. Applications are built from graphical workflows, configurations, and proprietary modules. Despite this, the rights to the work results must be explicitly regulated.

Transfer of Usage Rights

Firstly, the contract must stipulate that the client receives all necessary usage rights to the individually created components of the application. Anything the developer independently creates—be it a specific workflow design, custom scripts within the platform, or a particular module compilation—should be available for the client's use, editing, and, if agreed, exclusive use. From a legal perspective, the developer holds copyright to such creative work (Section 69a (3) UrhG for software and Section 2 UrhG generally). Without a contractual agreement, these rights would remain with the developer, allowing the customer to use the result only within the contract's intended purpose (Section 31 (5) UrhG, the purpose transfer principle). An explicit rights transfer clause is therefore essential.

Limits of Rights Transfer

At the same time, the contract must address the limits of this transfer of rights. Platform operators typically retain their own rights to their modules. License terms for no-code tools may specify that users have only a limited license to prefabricated modules and cannot freely transfer them. Thus, the contract should clarify that the developer can only transfer the rights that they possess, excluding the platform's proprietary materials. Practically, this means the client gains rights to the specific combination and configuration, but does not acquire rights to the platform's source code or generic modules if these are copyright-protected and owned by third parties.

In such cases, the client must conclude a user agreement (license agreement) with the platform provider, granting permission to use the generated application. Without compliance with the platform's terms of use, the application might not be fully usable or transferable. Therefore, both parties should be familiar with the terms and conditions/license conditions of the chosen tool and contractually agree to abide by them. This is crucial for maintaining a clean chain of rights.

Handover of Documentation and Access Data

The issue of handing over documentation or "source code equivalents" is a frequent concern. Since classic source code is often absent, the contract should specify what the developer will provide to the customer instead. This could include the following:

Without such agreements, challenging situations can arise. Example: A startup has a complex business logic developed by a service provider within a no-code database like Airtable, complete with automations. If the contract does not specify the release of configuration or documentation, the startup might later wish to hire another developer for extensions. The original service provider might refuse to disclose settings, formula definitions, or automations. Legally, the startup would likely have no claim to this information.

According to case law (BGH, judgment of 16.12.2003 — X ZR 129/01), a claim to source code disclosure exists only in exceptional cases for individual software, specifically if the contract's purpose cannot be achieved without the code, or if it was clear the customer intended further development. In this scenario, the original developer could argue: "You can use the Airtable app as agreed; that's all I owe you." The startup would then be in a difficult position. To prevent this, considering software escrow contracts might be a viable solution.

To avoid such disputes, the contract should precisely specify which documents, files, and accesses the client will receive at the end. A possible clause could state: “The contractor shall hand over to the client all documents, files, and accesses required for the use, maintenance, and further development of the application created. This includes in particular: [...]” This list might cover project file exports, detailed workflow documentation, admin access data to the platform, and API documentation. For larger projects, even considering escrowing the source code (e.g., configuration data or project status with an independent trustee) could provide security if the developer fails or becomes insolvent.

From the developer's perspective, protecting sensitive internal knowledge is understandable. Therefore, protection mechanisms can be included, such as releasing information only after full payment or obliging the customer to maintain confidentiality. However, both parties must have the same understanding of what will be delivered at the end, whether it's source code, configuration data, or guaranteed access to all essentials. A clear contractual provision prevents disappointment and legal disputes.

Note: In internal citizen development projects, the question of who owns the rights to an employee-created application often arises. In Germany, Section 69b UrhG applies: If a computer program is created by an employee as part of their duties, the employer automatically holds all property rights to it. Nevertheless, it's advisable to specify in employment contracts or internal guidelines that citizen developers' results belong to the company. Section 69b UrhG does not apply to external freelancers; here, the transfer of rights must be contractually agreed, otherwise copyrights remain with the developer. This topic warrants meticulous attention to detail.

Maintenance and Servicing of No-Code Systems

After development, the maintenance and support phase begins. Especially with no-code systems, questions arise regarding the structure of maintenance contracts and how they differ from conventional support agreements. First, the legal classification is crucial: Is ongoing support a service contract or a contract for work?

Under German law, a service contract (Section 611 BGB) requires action without guaranteed success. In contrast, a contract for work and services (Section 631 BGB) targets a concrete success (a "work") that the client accepts. In IT practice, maintenance contracts often establish continuing obligations with regular duties, such as installing updates, rectifying errors, and system monitoring. Courts tend to classify such flat-rate support as service contracts.

Example: The Regional Court of Cologne ruled in 2015 (case no. 12 O 186/13) that a flat-rate agency contract for ongoing website support was overall a service contract, despite some work elements. The focus was on the continuous availability of the service, not a one-off work result.

For no-code maintenance, the contract should clearly state that maintenance and servicing are performed as a service contract, provided this aligns with the parties' intent. Otherwise, a customer might later argue that every minor change constitutes an acceptance-eligible work, granting them special rights like refusal of acceptance or termination under § 648 BGB. Explicitly declaring "ongoing support as a service without guarantee of success" provides clarity. Of course, development services (work character) and maintenance (service) can also be separated, for example, through two distinct contracts or separate sections within the same contract. This separation ensures that warranty and acceptance apply to development projects, while different rules (duty of care, term, notice periods) govern subsequent support. For expert advice on SaaS agreements, see our guide on drafting contracts for SaaS companies.

Scope of Maintenance Services

In terms of content, a maintenance contract for no-code platforms should precisely detail the services the provider will deliver. Typical inclusions are monitoring the application, regular updates (if offered by the platform provider), backup creation, performance monitoring, and bug-fixing for faults. Since many of these activities occur "in the background," agreeing on reporting obligations is advisable. For instance, the developer could submit monthly reports on tests performed, errors rectified, and updates installed. This fosters transparency and trust, allowing the client to see the value they receive, even if no visible problems have occurred. Such reporting helps avoid misunderstandings, like the perception that "nothing is being done."

Handling Additional Requirements and Platform Updates

A specific challenge with flat-rate maintenance involves managing additional requirements. While the client often pays a fixed amount for the service provider to be available and resolve minor issues, extensive new tasks might arise unexpectedly. A well-designed contract will include mechanisms to address this. For example, it can stipulate that major changes or extensions are not covered by the flat rate and must be commissioned and paid for separately. This prevents disputes over whether an activity falls under "maintenance" or constitutes a new development project.

Updates from the platform provider are a crucial consideration, particularly for no-code platforms, as many SaaS services constantly evolve their functions. The contract should contain a clause on how to handle such changes. If the platform deactivates a feature or alters its operating mode, adjustments to the application may become necessary. It must be clear whether the developer is responsible for these adjustments as part of the maintenance contract (potentially free up to a certain effort) or if they will be invoiced additionally as a change request. Without this agreement, the client might assume all changes are covered, while the developer views them as a new order. A transparent middle ground could be: minor adjustments due to platform updates are included; major changes necessitate a contract adjustment. Defining this threshold is essential.

Contract Term and Termination

Finally, the contract term and termination modalities require careful attention. For service contracts, the principle of "pacta sunt servanda" generally applies: the contract runs for its agreed duration and can only be terminated with notice, unless there's good cause under Section 626 BGB. Fixed minimum terms or notice periods are common, offering planning security for the developer and commitment for the customer. It's advisable to include clear deadlines in the maintenance contract, e.g., "terminable for the first time at the end of 12 months with 3 months' notice, thereafter renewable annually."

A special case is the termination option under Section 648 BGB for contracts for work and services. This should not apply to pure maintenance contracts as long as they are classified as service contracts. Therefore, clear wording is paramount to avoid a mixed character. Otherwise, a judge might dissect the contract and treat parts of it as a contract for work.

Collaboration Between Citizen and Professional Developers

A growing number of companies are adopting a mix of citizen development and professional development. This approach involves specialized users without traditional programming training (citizen developers) creating simpler applications or prototypes using low-code/no-code tools. Professional developers are then engaged for complex tasks or overall architectural design. This collaboration can be highly productive, blending departmental expertise with IT technical know-how. However, specific contractual arrangements are necessary to ensure seamless cooperation.

Defining Roles and Responsibilities

Firstly, it is essential to clearly define roles and responsibilities. The contract (or project plan) should specify which tasks the external developer or agency will undertake, and what will be handled by the internal citizen developer or the client's team. For example: “The client provides a technical employee who performs the basic configuration in platform XY. The contractor then develops individual modules and integrates them into existing systems.” Such a description prevents overlaps and gaps, ensuring both sides know their respective responsibilities.

Addressing Liability in Overlapping Work Areas

Liability issues particularly arise where work areas overlap. If the client is involved in building the application, the contract should stipulate that the professional developer is not liable for errors caused by the client's interventions. Conversely, the client must ensure its employees possess the necessary knowledge and authorization to work with the platform; the external developer cannot bear full responsibility for amateur errors. One approach could be for citizen developers not to alter sensitive areas, such as security-relevant settings or integrations with third-party systems, without consultation. Alternatively, the external service provider could review all changes before go-live. While such coordination can be informal, a brief note in the contract helps clarify expectations. Additionally, clarifying arrangements with external freelancers is vital to prevent misclassification and associated liabilities.

Merging Work Results and Ensuring Data Security

Merging work results is another key consideration. When multiple individuals work on a low-code platform, technical and organizational conflicts can arise. Defining access rights and environments can be beneficial. For instance, the citizen developer could work in a test workspace, while the professional developer handles deployment to the productive workspace. While not needing exhaustive detail in the contract, at least an obligation for cooperation and coordination should be mentioned. Both parties should commit to constructive collaboration, communicating changes, and adhering to common standards to ensure a consistent end product. This can be broadly formulated as a cooperation clause.

Another aspect is confidentiality and data protection. Collaborative efforts inevitably involve information exchange between external developers and internal employees. A non-disclosure agreement (NDA) is standard practice, but the contract can reinforce both sides' commitment to protecting confidential information. This is particularly relevant if citizen developers gain insight into the external developer's code or methods, and vice versa. Agreement on who has administrative access to which systems and how sensitive data is handled is also critical to avoid compliance problems. For more information, refer to our confidentiality strategy for startups.

Rights Transfer in Collaborative Projects

Finally, rights transfer is again a significant factor. If internal and external developers collaborate on a product, it must be ensured that the client can ultimately use all components. The external developer will typically transfer their rights to their contributions, while Section 69b UrhG applies to internal citizen developers (employer's rights to software). Nevertheless, the contract can include a clause clarifying the client's entitlement to use all project results, regardless of who created them. This also provides clarity for any involved freelancers or subcontractors.

Key to Successful Cooperation

In conclusion on this point: Citizen developers and professionals can work hand-in-hand, allowing a company to benefit from both rapid development and quality assurance. For this to succeed, the contract should define the rules of cooperation: no unregulated interventions, transparency about changes, clear responsibilities, and a coordination mechanism. For example, regular meetings could be agreed upon, or a technical lead (like the professional developer as the final quality inspector) could be appointed. Such measures prevent misunderstandings. Training sessions can also be arranged, where the professional developer trains the citizen developer, which can be listed in the contract as a service (know-how transfer).

Fazit

No-code and low-code technologies offer new opportunities in software development, but contractual regulations must keep pace. A contract for a no-code/low-code project should be specifically tailored to the unique aspects of this methodology. We recommend clear clauses addressing the scope of services, rights of use (including source code equivalents), liability for platform failures, and maintenance modalities.

The developer's duty to inform about risks and limitations should also be emphasized to preempt conflicts. Maintenance contracts in the no-code environment typically need to be structured as service contracts, requiring transparent agreements on the scope of support. Furthermore, combining citizen developers with professional developers can be a recipe for success, provided roles, cooperation, and responsibility are contractually defined.

Overall, standard templates are often insufficient for effectively covering contracts for no-code or low-code development. Both parties must diligently verify that all crucial points are addressed, from specific "no-code contract" requirements to "low-code liability" risks and "no-code platform maintenance" regulations. A well-founded, individualized contract design fosters security and trust. It ensures that innovative technologies can be utilized in a legally sound manner, protecting both clients and developers in unforeseen circumstances. This framework paves the way for successful collaboration, allowing the full benefits of the no-code/low-code approach to be realized.