Contractual regulations for no-code/low-code software development

No-code and low-code platforms enable rapid software development without extensive manual programming. Applications are increasingly being developed on the basis of tools such as Bubble, Webflow, Airtable or Auth0 in order to save time and costs. However, these modern approaches bring with them particular contractual challenges. Clients and developers need to be aware of the fact that a no-code contract must be drafted just as carefully as a traditional IT contract. Otherwise there are risks: Unclear performance obligations, disputes over missing source code, dependencies on third-party platforms or gaps in usage rights could lead to conflicts. The most important points are highlighted below to ensure that contracts for no-code/low-code software development are drafted professionally and legally compliant – neutrally and soundly from a legal perspective.

Special contractual clauses for no-code/low-code development

If software is created in whole or in part using no-code/low-code tools, contracts should contain some special clauses that go beyond standard software contracts. First of all, it is important to clearly define the scope of services: what exactly does the developer owe? In traditional projects, the delivery of source code and installable software is often owed. In the case of no-code projects, there is often no classic source code, but rather a configured application on a platform. It is therefore necessary to contractually define what is considered the end result – e.g. the functional application on the selected platform including all workflows, settings and required access.

In addition, rights of use and ownership should be expressly regulated. The client must be granted the right to use the developed no-code application as intended ( exclusively, if desired). At the same time, it must be made clear that rights to the no-code platform itself or to prefabricated modules are not transferred – the customer therefore does not acquire ownership of the tool or the standard modules, but only of the individually created components of the application. For example, the customer may use a website created on Webflow and change its content, but of course does not acquire any rights to the Webflow software or the platform’s general design templates. Such clauses sound obvious, but are worth their weight in gold in the event of a dispute. Headings such as “Rights of use software development” or “Rights to no-code components” help to emphasize the importance.

Regulations on third-party providers and integrations are another important part of the contract. No-code/low-code solutions often integrate external services – such as payment providers via API, cloud databases or other SaaS services. The contract should clarify who is responsible for these third-party services and who bears the costs. For example, does the client have to provide their own licenses or subscriptions for Airtable, Webflow & Co. Does he bear the fees directly, or does the developer procure the necessary accounts and invoice them to the customer? Such financing and cooperation obligations on the part of the client should be expressly included in the contract (see § 642 BGB on the client’s obligation to cooperate). It should also be noted that the developer is not responsible for the performance of these external services, unless otherwise agreed. Example: If an email service is connected and it fails, the developer must not be liable for this without checking.

Practical tip: It often makes sense for the client to set up their own accounts with the required no-code platforms at an early stage (or to grant the developer access to their account). This way, the client retains control and the finished application can be easily transferred to the client at the end of the contract. Contracts should stipulate that the application created is ultimately transferred to the client’s account or that the client at least receives full administrator rights. This means that the customer is not faced with a closed door when the business relationship ends.

Developer’s duty to inform about limits and risks

A key question is whether the developer has a duty to inform the customer about the limitations, risks and dependencies of third-party platforms. In principle, each contracting party must take into account the rights, legal interests and interests of the other party (Section 241 (2) BGB). In the project context, this gives rise to a duty on the part of the software developer to provide advice and information. He may not remain silent if he recognizes that certain customer requirements cannot be met with the selected no-code/low-code solution or if there are significant risks (such as dependence on a cloud platform). The scope of this duty to advise depends on the circumstances, in particular on the expertise of the client. In the case of a technically inexperienced customer, the developer must provide a more comprehensive warning; in the case of a very knowledgeable customer, less explanation can be assumed.

In concrete terms, this means that the developer must inform the client of the main limitations of the no-code tools before the contract is concluded and during implementation. If, for example, a certain desired functionality cannot be implemented with the selected platform or can only be implemented with workarounds, the client must be informed of this at an early stage. Risks such as scaling limits (e.g. maximum number of users or data volumes that the system can handle) must also be disclosed. The risk of a vendor lock-in – i.e. dependence on a single provider – should also be addressed. No-code solutions are often based on proprietary systems; the customer should know that changing the platform at a later date can involve considerable effort.

Practical example: An agency suggests to a start-up that its application should be developed entirely on a no-code platform, as this is faster. However, the agency is aware that the platform does not fully meet certain data protection requirements of the European market and that performance problems could occur with a high volume of users. It is obliged to inform the client about these points. If it fails to do so, it could be liable for damages – e.g. due to a breach of pre-contractual obligations ( culpa in contrahendo) or secondary obligations arising from the contract. In German contract law for work and services, the developer is even considered to be partly at fault (§ 254 BGB) if he does not address recognizable errors in the client’s concept. Therefore: Transparency from the outset protects both sides.

In addition, the duty of disclosure also includes reference to dependencies on third-party providers. The customer should understand that their fully developed application is ultimately only as stable and available as the underlying platform allows. If there are known restrictions (e.g. certain API limits or lack of offline options), the developer should clearly state this. If necessary, the developer must also point out alternatives (for example: “Function X does not work with this no-code tool – you would need a custom development or an additional plugin for this”). This is the only way the client can make an informed decision. Ideally, this advice should be documented in writing or recorded in the contract in order to avoid disputes later on.

Liability in the event of failure or discontinuation of no-code platforms

A particular risk in software development with no-code/low-code is the dependency on the availability and stability of the platform used. What happens if services such as Bubble, Webflow, Airtable or Auth0 fail, are temporarily restricted or, in the worst case, cease to operate? Contracts must clearly allocate who bears which risk in such cases.

As a general rule, the developer is responsible for the contractually agreed service, e.g. the creation of a functioning application on the selected platform. However, the developer is generally not responsible for the ongoing operation of the platform itself – this is the responsibility of the platform provider. The contract should therefore include a limitation of liability that exempts the developer from liability for circumstances beyond their control (see Section 276 (1) BGB on liability). An example would be a clause that defines outages or performance degradation of the underlying SaaS platform as force majeure or circumstances beyond the developer’s control. This can clarify that such external events do not constitute a breach of contract by the developer.

Example: The business app created by the developer runs entirely on Airtable. One day, Airtable has a major outage or changes its API, causing parts of the app to stop working. If nothing has been arranged, the client could try to make a claim against the developer for a defect or failure. A suitable contractual clause, on the other hand, makes it clear that as long as the developer is not responsible for the error (e.g. because it was not caused by their own actions), they are not liable for it. Instead, it would be a case for the platform provider’s support or (if agreed) joint crisis management, in which the developer assists with troubleshooting for an additional fee.

In addition to technical failures, the loss of the platform as a whole must also be considered. No-code platforms can change their business models, implement drastic price increases or even be discontinued. In this case, it should at least be contractually stipulated that such a discontinuation can be seen as a change in the basis of the business. If necessary, the parties can agree to renegotiate in such a case or that the client has a special right of termination if the basis of the project (the available platform) ceases to exist. As a rule, the developer will not be able to guarantee that a platform will exist forever or remain unchanged – this entrepreneurial risk is effectively borne by the client who has opted for the no-code route. However, the developer can provide support, for example by showing alternative scenarios (migration to another platform, export of data, etc.).

In any case, it is advisable to adapt liability and warranty to the specifics. In traditional software contracts, there are warranty periods for defects and often extensive exclusions of liability for consequential damages. In the no-code context, the warranty should be clearly limited to ensuring that the created application functions in accordance with the contract at the time of acceptance. Subsequent changes or failures of the platform would not be a defect in the work performance, but rather changes to the environment. The developer’s liability can be contractually excluded or limited to cases of intent and gross negligence (whereby such limitations of liability must be carefully formulated in the GTC so as not to violate Section 307 BGB). Of course, mandatory liability, such as for personal injury or under product liability law, must remain unaffected – however, such liability rarely exists in the pure software sector. Important: Both parties should check the liability provisions carefully so that it is clear who has to bear what damage in an emergency.

Rights transfer and missing source code output

In the case of conventional software development, the transfer of copyright usage rights to the software is usually agreed in the contract – often in conjunction with the handover of the source code to the client. This is more difficult in the no-code/low-code area: There is often no comprehensive source code to hand over, as the application consists of graphical workflows, configurations and proprietary modules. Nevertheless, the rights to the work results must be regulated.

First of all, it must be stipulated that the client receives all necessary usage rights to the individually created components of the application. Everything that the developer has created independently – be it a specific workflow design, their own scripts within the platform or a special compilation of modules – should be used, edited and (if agreed) used exclusively by the client. From a legal perspective, the developer has a copyright to such creative work (Section 69a (3) UrhG for software and Section 2 UrhG in general). Without a contractual agreement, this would remain with the developer and the customer would only be allowed to use the result within the scope of the purpose of the contract (Section 31 (5) UrhG, the so-called purpose transfer principle). An explicit rights transfer clause is therefore essential.

At the same time, the contract must address the limits of this transfer of rights. The platform operators usually retain their own rights to their modules. License terms for no-code tools may stipulate that users only have a limited license to the prefabricated modules and are not allowed to pass them on freely. The contract should therefore make it clear that the developer can only transfer the rights that lie with them. This excludes the platform’s own material. In practical terms, this means that the client receives the rights to the specific combination and configuration, but does not receive any rights to the platform’s source code or generic modules if these are protected by copyright and belong to third parties. In case of doubt, the client must conclude a user agreement (license agreement) for the platform itself, which allows him to use the generated application. Without compliance with the platform’s terms of use, it is otherwise possible that the application may not be fully used or transferred. Therefore, one recommendation is that both parties should be familiar with the terms and conditions/license conditions of the selected tool and contractually agree to comply with them.

The question of handing over documentation or “source code equivalents” is a particular headache for many. Since there is no source code in the classic sense, it should be determined what the developer hands over to the customer instead. This could be the following points, for example:

• Documentation and configuration files: The developer should document all relevant workflows, settings and logic. This also includes exporting the project configuration, where technically possible (e.g. JSON definitions, export files).
• Access data: If the application was created on the developer’s account, the customer must at least receive administrator access or – better – the complete transfer to a customer account (e.g. transfer of a Webflow website to the customer’s account, entry of the customer as owner of an airtable base).
• Scripts and external code components: If low-code does contain some code (e.g. self-written scripts, style sheets or plugins), these must be released in the source code. Basically, the same standard applies here as for individual software: the customer should receive what has been individually programmed on request.

Without such agreements, unpleasant situations can arise. Example: A start-up has a complex business logic in a no-code database (such as Airtable with automation) developed by a service provider. Nothing has been agreed in the contract regarding the release of the configuration or documentation. Later, the start-up wants to commission another developer with extensions and demands that the original service provider disclose all settings, formula definitions and automatisms. Legally, the start-up would probably have no claim to this. According to case law (BGH, judgment of 16.12.2003 – X ZR 129/01), a claim to the disclosure of source code only exists in exceptional cases with individual software, namely if the purpose of the contract cannot be achieved without the code or if it was apparent that the customer wanted to develop further itself. In this case, the original developer would argue: “You can use the Airtable app as agreed; that’s all I owe you.” The start-up would then be trapped.

To avoid such disputes, the contract should specify precisely which documents, files and accesses the client will receive at the end. A possible clause could read: “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: [list of specific items].” This list could include the export of project files, detailed documentation of workflows, admin access data to the platform, API documentation, etc. In addition, depending on the size of the project, you could even consider escrowing the source code: for example, configuration data or the project status could be deposited with an independent trustee who would hand it over to the customer if the developer were to fail or become insolvent.

From the developer’s point of view, it is understandable that sensitive internal knowledge needs to be protected. Protection mechanisms can therefore be provided, for example that the information is only released after full payment has been made or that the customer is obliged to maintain confidentiality. However, it is important that both sides have the same understanding of what will be delivered in the end – whether it is source code, configuration data or at least the assurance of access to all the essentials. A clear contractual provision prevents disappointment and legal disputes.

Note: In internal citizen development projects(more on this later), the question often arises as to who owns the rights to an application created by an employee. Section 69b UrhG applies here in Germany: If a computer program is created by the employee as part of their duties, the employer is automatically entitled to all property rights to it. Nevertheless, it is advisable to make it clear in employment contracts or internal guidelines that the results of citizen developers belong to the company. Section 69b UrhG does not apply to external freelancers – the transfer of rights must be contractually agreed here, otherwise copyrights remain with the developer. It is therefore worth leaving no detail open on this topic.

Maintenance and servicing of no-code systems

After development, the maintenance and support phase begins. With no-code systems in particular, the question arises as to how maintenance contracts should be structured and whether they differ from conventional support contracts. First of all, the legal classification is important: is the ongoing support a service contract or a contract for work? Under German law, a service contract (Section 611 of the German Civil Code (BGB)) only requires action without guaranteed success, whereas a contract for work and services (Section 631 BGB) has a concrete success (a “work”) as its object, which the client accepts. In IT practice, maintenance contracts are often continuing obligations with regular duties (installing updates, rectifying errors, monitoring the system). The 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 a service contract overall despite some work elements – because the focus was on the ongoing availability of the service, not a one-off work result.

For no-code maintenance, this means that the contract should make it clear that maintenance and servicing services are carried out as a service contract, provided this is what the parties want. Otherwise, a customer could later argue that every small change is a work capable of acceptance and that he has special rights (refusal of acceptance, termination according to § 648 BGB, etc.). The explicit declaration “ongoing support as a service without guarantee of success” creates clarity. Of course, development services (work character) and maintenance (service) can also be clearly separated – for example by means of two contracts or separate sections in the same contract. This separation ensures that warranty and acceptance apply to development projects, while other rules (duty of care, term, notice periods) apply to subsequent support.

In terms of content, a maintenance contract for no-code platforms should describe exactly what services the service provider provides. Typical points are: Monitoring of the application, regular updates (if provided by the platform provider), backup creation, performance monitoring, and bug-fixing when faults occur. As many of these activities take place “in the background”, it is advisable to agree reporting obligations. For example, the developer can submit a monthly report on tests carried out, errors rectified, updates installed, etc. This creates transparency and trust – the client can see what they are paying for, even if no visible problems have occurred. In this way, misunderstandings can be avoided (keyword: “Nothing is being done here!”).

A particular challenge with flat-rate maintenance is how to deal with additional requirements. The client often pays a fixed amount for the service provider to be available and fix minor problems. But what if extensive new tasks suddenly arise that were not originally covered? A smart contract will provide mechanisms for this. For example, it can be stipulated that major changes or extensions are not covered by the flat rate and can only be commissioned (and paid for) separately. This avoids disputes as to whether a certain activity still falls under “maintenance” or already constitutes a new development project.

Updates from the platform provider should be considered, especially for no-code platforms: Many SaaS services are constantly changing functions. The contract should contain a clause on how to deal with such changes. If the platform deactivates a feature or changes the operating mode, for example, this may necessitate adjustments to the application. It must be clear here whether the developer is responsible for such adjustments as part of the maintenance contract (possibly free of charge up to a certain level of effort) or whether this will be invoiced additionally as a change request. Without this agreement, the client could assume that all changes are covered, while the developer sees them as a new order. A transparent middle ground could be: minor adjustments due to platform updates are included; major changes lead to a contract adjustment. It is important to define the threshold.

Finally, the contract term and termination modalities deserve attention. In the case of service contracts, “pacta sunt servanda” generally applies – the contract runs for the agreed duration and can only be terminated with notice (unless there is good cause in accordance with Section 626 BGB). Fixed minimum terms or notice periods are common so that the developer has planning security and the customer can commit himself. In this case, it is 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 aforementioned termination option under Section 648 BGB for contracts for work and services: This should not play a role in pure maintenance contracts as long as they are considered a service contract. It is therefore all the more important to avoid a mixed character through clear wording – otherwise, in case of doubt, a judge could take the contract apart and treat parts of it as a contract for work.

Collaboration between citizen developers and professional developers

More and more companies are relying on a mix of citizen development and professional development. This means that specialist users without traditional programming training (citizen developers) create simple applications or prototypes with low-code/no-code tools, while professional developers are brought in for complex tasks or the overall architecture. This collaboration can be very fruitful – it combines specialist knowledge from the departments with technical know-how from IT. However, some contractual arrangements should be made to ensure smooth cooperation.

First of all, it is important to clearly define roles and responsibilities. The contract (or project plan) should specify which tasks the external developer or agency will take on and what will be done by the internal citizen developer or the client’s team. For example: “The client provides a technical employee who carries out the basic configuration in platform XY. The contractor then develops individual modules and integrates them into existing systems.” A description like this prevents overlaps and gaps. Both sides know who is responsible for what.

Liability issues arise in particular where the areas of work overlap. If the client itself is involved in building the application, it should be contractually stipulated that the professional developer is not liable for errors caused by the client’s interventions. Conversely, the client should ensure that its employees have the necessary knowledge and authorization to work with the platform – the external developer cannot bear full responsibility for amateur errors. One approach could be that the citizen developer does not change certain sensitive areas(e.g. security-relevant settings or integrations with third-party systems) without consultation, or that the external service provider checks all changes before the go-live. Such coordination processes can be handled informally, but a brief note in the contract does no harm to ensure that expectations are clear.

Merging the work results is also an issue. If several people are working on a low-code platform, there is a risk of conflicts (in both the technical and organizational sense). It can be useful to define access rights and environments: For example, the citizen developer works in a test workspace and the professional developer takes over deployment to the productive workspace. This does not have to be described in detail in the contract, but at least the obligation to cooperate and coordinate should be mentioned. Both parties should be obliged to work together constructively, communicate changes and adhere to common standards so that the end product is consistent. This can be formulated more generally as a cooperation clause.

Another aspect is confidentiality and data protection. When external developers and internal employees work together, information is inevitably exchanged. An NDA (non-disclosure agreement) is standard these days, but the contract can re-emphasize that both sides will protect each other’s confidential information. This applies in particular if citizen developers gain insight into the code or methods of the external developer (and vice versa). It should also be agreed who has administrative access to which systems and how sensitive data is handled in order to avoid compliance problems.

Last but not least, the transfer of rights plays a role here again: if internal and external developers work together on a product, it must be ensured that all parts may ultimately be used by the client. As usual, the external developer will transfer his rights to the contribution (see above), while Section 69b UrhG applies to the internal citizen developer (employer’s rights to software). Nevertheless, the contract can contain a clause that clarifies that the client is entitled to use all results of the project, regardless of who created them. This also creates clarity for any freelancers or subcontractors involved.

Conclusion on this point: Citizen developers and professionals can work hand in hand – the company benefits from fast development and quality assurance at the same time. For this to succeed, the contract should define the rules of cooperation: No unregulated interventions, transparency about changes, regulated responsibilities and a mechanism for coordination. For example, you could agree regular meetings or appoint a technical lead (such as the professional developer as the final quality inspector). This avoids misunderstandings. Training sessions can also be arranged: The professional developer can train the citizen developer, which in turn can be listed in the contract as a service (know-how transfer).

Conclusion

No-code and low-code open up new opportunities in software development – but the contractual regulations must keep pace. A contract for a no-code/low-code project should be specifically tailored to the particularities of this method. Clear clauses on the scope of services, rights of use (including source code equivalents), liability in the event of platform failures and maintenance modalities are recommended. The developer’s duty to inform about risks and limitations should also be emphasized in order to avoid later conflicts. Maintenance contracts in the no-code environment usually have to be structured as service contracts and require transparent agreements on the scope of support. Finally, the combination of citizen developer and professional can be a recipe for success – as long as it is contractually defined who takes on which role and how cooperation and responsibility are distributed.

Overall, standard templates are often not sufficient to cover contracts for no-code or low-code development. Both parties should carefully check whether all important points are covered – from “no-code contract” specifics to “low-code liability” risks and “no-code platform maintenance” regulations. A well-founded, individual contract design creates security and trust. It ensures that innovative technologies can be used in a legally sound manner and that both clients and developers are protected in the event of an emergency. This means that nothing stands in the way of successful collaboration – and the benefits of the no-code/low-code approach can be fully exploited.