Legally compliant contract drafting for software development on no-code platforms

No-code and low-code platforms enable start-ups and agencies to develop software and digital products quickly and without in-depth programming knowledge. However, when software development is carried out using SaaS services and no-code tools such as Airtable, Webflow, AWS Honeycode or Azure Logic Apps, significant legal issues arise. A no-code contract must be drafted just as carefully as a traditional software contract in order to be legally secure. Otherwise, there are risks – from unclear performance obligations and disputes over source code distribution to gaps in usage rights. We highlight the most important aspects below: How should maintenance contracts be classified in the case of no-code? When is there a right to source code or functional equivalents? How do you regulate rights of use for individually created components versus platform components? And which practical clauses should not be missing from any “no-code SaaS law” contract? This article provides a sound overview of what is important and underlines why legally compliant software contracts in this area can only be successful with professional advice.

1. maintenance contracts for no-code/SaaS: service or work contract?

A central point in contract design is the legal classification of maintenance and service contracts for no-code applications. In Germany, the BGB distinguishes between a service contract (Section 611 BGB) and a contract for work (Section 631 BGB). Service contract means: the service provider owes an action (i.e. efforts), but no specific success. Contract for work means: a specific result is owed (a “work”) that the client can accept – for example, a fully programmed application that meets certain requirements. This distinction has significant consequences: In the case of a contract for work and services, warranty rights and acceptance apply, and the client may be able to terminate the contract before completion in accordance with Section 648 BGB (formerly Section 649 BGB). With a service contract, on the other hand, “pacta sunt servanda” applies – the contract generally runs for the agreed duration and there is no entitlement to a specific result, only to diligent action.

Maintenance contracts in the no-code environment (e.g. for the ongoing support of a Webflow website or an Airtable database) are usually structured as a continuing obligation with ongoing duties. Typically, the client pays a monthly flat-rate fee for the service provider to provide availability and monitoring-related services – such as regular monitoring, installing updates, fixing bugs or simply guaranteeing a certain response time in the event of an error. This raises the question: Is this a service contract or a contract for work? Case law tends to classify such flat-rate agreements as a service contract. For example, the Regional Court of Cologne ruled in a high-profile case (judgment of 20.02.2015 – Ref. 12 O 186/13, “Internet agency flat rate”) that a comprehensive agency agreement with a monthly flat fee is to be regarded as a contract for services. Although individual elements (such as the one-off creation of a website) had the character of work, the ongoing marketing and SEO services, which are open-ended activities, predominated. The main reasons for the classification as a service contract were: The agreement was designed as a long-term continuing obligation, the remuneration was owed regardless of a single success, and the focus was on the ongoing availability of services when required, not on the production of a one-off end product. This is exactly the same picture with maintenance contracts for no-code software: the contractor stands ready and provides services as required, which do not always result in a tangible “work”.

In practice, this means: clarify the type of contract! If the ongoing support of a no-code application has been agreed, it should be expressly stipulated that – if this is the intention – it is a service contract that includes continuous cooperation without a guarantee of success. Otherwise, the client could attempt to classify individual results as “works” and, for example, demand acceptance or terminate the contract prematurely. Conversely, if a contract combines both development services (work) and maintenance (service), a mixed contract exists. In this case, it is advisable to clearly regulate the types of service separately (e.g. in separate parts of the contract or even separate contracts, e.g. a development contract and a subsequent maintenance contract). This avoids confusion as to which legal rules apply in case of doubt.

Flat-rate remuneration and verifiability of the service: A particular problem with flat-rate maintenance contracts is the verifiability of the services. Often, the client can hardly see from the outside what the service provider is doing in the background – especially if there are few faults (example: the service provider receives a monthly flat fee for “monitoring” a no-code app, but the app runs stably so that no interventions are necessary). Nevertheless, the remuneration is owed, as the service here consists of the service provider’s readiness and availability. In legal terms, this is justified by the nature of the agreement and its character as a service contract: The contractor provides its time and expertise on an ongoing basis, which already constitutes the remunerated service – regardless of whether a specific error had to be rectified. In the above-mentioned Cologne Regional Court case, the court argued that the monthly fee was to be paid “regardless of the services actually provided” and that it was precisely the constant readiness to work that was being compensated. From the point of view of good faith (Section 242 BGB), a contractor should nevertheless ensure transparency: reporting obligations in the contract are recommended (e.g. a monthly report on tests carried out, updates, backups, etc.). In this way, the client can see that the service provider has been active and the relationship of trust remains intact. It also avoids later disputes as to whether “nothing was done” – both sides know which invisible tasks were performed.

To summarize: In the case of maintenance contracts in the no-code area, there is much to be said for classifying them as a service contract. This should be clearly stated in the contract and the scope of the activities owed (readiness, monitoring, troubleshooting, etc.) should be precisely described. Flat-rate remuneration for readiness is common – however, mechanisms should be agreed on how additional services are to be handled: If there are complex activities that were not originally covered, a remuneration adjustment in accordance with the law on contracts for work and services may be considered. In fact, the Federal Court of Justice (judgment of January 8, 2002 – case no. X ZR 6/00) has ruled that even in the case of a flat-rate contract for work and services, the contractor can demand additional remuneration if the customer has requested considerable additional services that were not originally planned. Applied to maintenance contracts, this means that if additional development tasks are taken on as part of a lump sum that go well beyond monitoring, it should be contractually clarified whether these are to be remunerated separately. Clear regulations and a clear separation of the basic flat rate and additional services prevent anyone from having to invoke surprises later on – in case of doubt, Section 242 of the German Civil Code (BGB) (good faith) is otherwise used as a loophole for a fair balancing of interests, which means unnecessary legal uncertainty.

2. publication of source code or functional equivalents for no-code projects

Start-ups and IT project managers in particular value not only having a running product as a result of software development, but also access to the “blueprint” – traditionally the source code. However, this issue is particularly relevant for no-code platforms: there is often no conventional source code because the application consists of graphically configured workflows, databases or proprietary modules, for example. So what happens when the customer demands: “Give me the source code or something equivalent”?

First, a look at the legal situation and case law for classic software development: Whether a client is entitled to the release of the source code is determined by the general interpretation of the contract and copyright law in the absence of a special regulation. According to Sections 133, 157 BGB, a contract is to be interpreted as required by good faith in consideration of common usage – in short: What did the parties agree according to objective understanding? And Section 31 (5) UrhG contains the principle of transfer of purpose: If rights of use to a copyrighted work (e.g. software) have been granted, in case of doubt they only extend to what is necessary to achieve the purpose of the contract. For software, this means that the client generally receives the rights to use the program as agreed – but nothing more, unless expressly agreed otherwise.

In its case law, the Federal Court of Justice has developed groups of cases as to when a source code disclosure claim exists and when it does not (see BGH, judgment of December 16, 2003 – X ZR 129/01 and BGH, judgment of January 30, 1986 – I ZR 242/83):

• Standard software vs. customized software: If standard software is purchased or customized, there is generally no entitlement to the source code. The courts argue that the customer can also use the software without the source code and that the purpose of the contract (use of the standard solution) does not require it to be handed over. The Higher Regional Court of Munich already ruled in 1991 (case no. 25 U 2586/91) that the source code does not have to be supplied with standard software unless otherwise agreed.
• However, if individual software (i.e. an application developed specifically for the customer) was commissioned, it depends on the circumstances of the individual case. The BGH requires a balancing of interests: According to the purpose transfer rule, the question is whether the intended use of the software requires knowledge of the source code. Principle: As a rule, no claim for surrender if the program can also be used without the source code. After all, the client can use the finished program without further developing it himself – this is likely to be the purpose of the contract, unless otherwise agreed.
• Exception – foreseeable need for changes: Only if it was apparent to the programmer (or was expressly agreed) that the client or a third party would later want to make further adjustments or extensions to the program can a claim for surrender be affirmed. A typical example: The client has made it clear that he needs the source code to further develop the software himself or to commission another developer with updates. If such a purpose was recognizably part of the contract, the source code is part of the performance owed – then the developer would have to hand it over (this is how BGH X ZR 129/01 is generally understood).
• No claim during ongoing maintenance: In its ruling of January 30, 1986 (case no. I ZR 242/83), the BGH made it particularly clear that the client has no claim to the surrender of the source code during the term of a maintenance or support contract. This is because as long as the original developer is contractually obliged to maintain the software, there is no need to entrust a third party with its further development – the purpose of the contract is for the developer to maintain the software himself. A release at this stage would disrupt the contractual structure and possibly disclose the developer’s business secrets without the customer needing the information for contractual use.

Applied to no-code platforms, this means that even if no classic source code exists, the contract must regulate what the functional equivalent of the source code is and whether the customer is entitled to it. With traditional software, you would have source code and object code. With an airtable solution, it could be the basic configuration, formulas, scripts or automations that the developer has set up, for example. With Webflow, it could be the exported HTML/CSS/JS code of the website, as well as access to the Webflow instance or the CMS. In Azure Logic Apps or AWS Honeycode, it could be workflow definitions, JSON exports or other description files that represent the developed logic. The term “functional equivalent” aims to provide the client with something with which they can use, reproduce or modify the developed application independently if necessary – even if there is no handwritten source code.

Contract interpretation according to BGB: In the absence of an express agreement, the above case law often means that there is no claim for surrender as long as the customer can use the no-code solution. Example: A start-up has an agency create a complex airtable database including automation. Nothing in the contract says anything about handing over the “files” or configuration. Later, the start-up wants to commission another service provider to make changes and demands that the original developer hand over all settings or export data. Does it have a legal claim to this? Probably not, because according to Section 31 (5) UrhG, the client will only have received the rights of use that are necessary to operate the Airtable base – and the base runs in Airtable, so the client probably has access as a user anyway. In case of doubt, the configuration as such (which may be considered a copyrighted software work or database work) remains with the developer. Without an agreement, the developer could therefore argue: “You can use the airtable base as intended, I don’t owe you any more.” Similarly with Webflow: If the contract only owes the provision of the current website, the developer does not have to hand over e.g. the editor access or the design export without a special agreement – as long as the website is accessible and usable as agreed, the purpose of the contract is fulfilled.

Tip: To avoid costly disputes, the contract should explicitly state what is to be handed over to the client. Ideally, a no-code contract should contain a clause such as: “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: e.g. export of project files, documentation of workflows, administrator access to platform XYZ, API documentation, etc.].” A source code deposit or escrow agreement is also helpful – also conceivable in a no-code context: For example, it could be agreed that the configuration data or designs are deposited with a notary or in an escrow account to which the customer has access if the developer is unavailable. In practice, the procedure is often simpler, as our example maintenance contract shows: There, although the source code initially remained with the service provider, it was agreed that the service provider must hand over the source code to the client or a third party nominated by the client on request. Such clauses translate the judicial “it depends” into clear contractual rights. With no-code SaaS projects in particular, it should also be borne in mind that the operation of the application is often tied to an account: it makes sense to stipulate that the application created is transferred to an account of the client or that the client at least receives administrator rights to it. Example: With Webflow, the developed website can be transferred to the customer’s account; with Airtable, the customer can be entered as the owner of the base. Contracts should stipulate that the service provider hands over full control at the end of the development phase – so that the client is not trapped when the business relationship ends.

To summarize: “Source code handover” in a no-code context is a tricky issue that must be proactively resolved contractually. Without a clear agreement, the transfer of purpose principle applies – and the customer often receives less than intended (only the use, but not the blueprints). Start-ups should therefore make absolutely sure that their no-code contract contains clauses on the documentation and handover of important components. Otherwise, they may find themselves with a locked system when they change developers. From the developer’s or agency’s point of view, on the other hand, it is legitimate to build in certain protective mechanisms – for example, that components are only released after full payment has been made or that proprietary secrets are kept. It is important that both sides have a clear common understanding of what will be delivered at the end of the contract – be it source code, configuration data or at least the assurance that they will have access to all the essentials.

3. scope of the rights of use: Individual software vs. platform components

Another key aspect of a legally compliant software contract in the no-code area is the regulation of usage rights. In traditional software development, the client is typically granted a right to use the created program – depending on the agreement, either simply (non-exclusive) or exclusively (exclusive), unlimited in terms of space and time, or with certain restrictions. With no-code projects, the situation is more complex because two levels come together here:

1. Individually created components: These are, for example, specific workflows, automations, designs, databases or other creative elements that the developer has created as part of the project. In principle, these can be protected by copyright – for example as a computer program (Section 69a UrhG) or as a database work (Section 4 (2) UrhG) or even as a design (design if it reaches a creative level). The developer can grant the client rights of use to these parts.
2. Platform and prefabricated components: No-code platforms themselves (such as Airtable, Webflow, Azure Logic Apps etc.) and their building blocks are subject to the license terms of their provider. Neither the developer nor the client “own” the source code of the platform. They only have rights of use by virtue of the contract with the platform provider (usually in the form of a SaaS subscription). In addition, open source libraries or engine components are often used in the background, to which third parties hold rights.

Obtaining exclusive rights to use software means that the client may use and exploit the software to the exclusion of all others – even the developer may not use it elsewhere without further ado. In the case of individual software development for a single customer, it is quite common to grant the customer exclusive rights of use to the code developed specifically for him. After all, they are paying for it and may want to exclude their competitors. In the no-code area, however, a clear distinction must be made as to what can be transferred exclusively. The developer can only transfer rights to which he himself is entitled. The developer has no rights to the underlying platform (e.g. the Airtable software or the Webflow engine) that he could pass on – only the platform provider owns the copyrights here. Consequently, the customer only receives these services for use within the scope of the platform license. In practical terms, this means that a client receives, for example, the right to use, edit and publish the Webflow website created – but does not acquire any rights to the Webflow software itself. Similarly with Azure Logic Apps: the workflow that a service provider configures for the customer may be creative, but the customer can only access it within the framework of Microsoft’s Azure platform. In terms of copyright, one could discuss whether the specific workflow as a computer program belongs to the service provider – but even if it does, the customer mainly needs permission to operate it on Azure. Microsoft’s SaaS contract ensures this (vis-à-vis the customer or the service provider, depending on the constellation).

Usual license models and exclusion clauses: In the IT industry, it is common to formulate contracts in such a way that the client receives all necessary rights of use to the deliveries, but the developer excludes certain general rights or third-party components. For example, there is often a clause stating that the client receives an exclusive right to use the individual software, but without the rights to generally usable modules, open source components or the development environment itself. These remain with the author or third-party providers. Instead, the customer receives a simple right of use, if necessary. Such a clause could read as follows: “The client receives the exclusive, temporally and geographically unrestricted right of use for all known types of use for the work results individually provided by the contractor (including software code, scripts, configurations and documentation). The Contractor shall remain entitled to freely use general concepts, reusable modules and its know-how. Rights to components originating from third parties (in particular to the no-code platform itself, to libraries or to open source software) are not transferred; in this respect, the client only receives the rights of use permitted under the respective license agreement.”

Such an arrangement ensures that the customer has full control over the results of the commissioned development (they can use, modify, sublicense, etc. as far as the individual service is concerned). At the same time, it protects the developer from unintentionally losing his general solutions or templates – and it protects the rights holders of third parties. The no-code agreement in particular should explicitly state that platform components and any integrated services are not part of the transfer of rights. For example: A contract appendix could list all third-party services used (e.g. “Services used: Airtable (cloud database), Webflow (web builder), Google Maps API, open source library XYZ under MIT license”…) and clarify that the client may only use these components within the scope of the respective terms of use.

Open source and engine components: An analogous case can be observed in game development: If a studio develops a game based on a game engine (such as Unity or Unreal), the publisher cannot claim the engine rights from the studio – these lie with Unity/Unreal. Similarly, with no-code, the “engine” or framework components are not exclusively available. Open source modules are often also used in no-code platforms (e.g. a JavaScript library that is used in Webflow export). The respective open source license automatically applies here: the client may use these components, but must comply with license conditions (e.g. naming of license texts, no exclusive use). A legally compliant software contract will take these points into account: In case of doubt, it does no harm to mention in the contract that certain software components are open source and under which license they are – this way the client knows what he may and may not do (e.g. he may not resell a certain component commercially if license prohibits this).

To summarize: The scope of the rights of use should be described very clearly in no-code development contracts. The client wants to ensure that it receives the necessary rights to all individual results – preferably exclusively, so that it can freely use and further develop the solution. At the same time, it must be accepted that the underlying infrastructure and generic modules cannot belong to them. It is therefore important to differentiate between individual software and platform components in the contract. Then it is clear what the customer is paying for (and acquiring ownership/rights of use) and what lies outside this area. If there is no such clarification, there is a risk of conflict: either the customer feels deceived because he thought “everything belongs to him”, or the developer sees his know-how at risk. This can be avoided with precise license clauses and industry-standard exclusions.

4. practical tips for no-code contracts

Finally, some practical tips on which points should definitely be regulated in contracts for no-code/low-code projects and where typical misunderstandings lurk:

• Clarify the scope of services and type of contract: Describe exactly what services the developer is providing (e.g. configuration of an airtable database, creation of a webflow website, implementation of API integrations, ongoing maintenance, etc.). Specify which are considered work services with acceptance (e.g. the initial creation of the application until it goes live) and which are considered services as part of a continuing obligation (e.g. subsequent support, SEO or hosting). This makes it clear from the outset whether it is a no-code contract in the sense of a contract for work, a service contract or a mixed contract. In the case of mixed forms, be sure to define the focus or separate services – this will prevent disputes about termination rights and remuneration.
• Remuneration, term and termination: In the case of flat-rate remuneration (flat-rate models), it should be transparent what is covered (e.g. up to X hours of support per month, monitoring, minor bug fixes) and what is not. Define how additional services are to be handled – for example, an hourly or daily rate for additional requirements that go beyond the package. Clearly define the term of the maintenance contract and notice periods. A long basic term with automatic renewal, as in the Cologne District Court case, is common, but remember: If it is a service contract, ordinary termination during the term is generally excluded, unless provided for in the contract. Contracts for work and services can be terminated by the client at any time (Section 648 BGB), which is a financial risk for the service provider. You should therefore coordinate the contract model and termination clauses in order to avoid unwanted loopholes (or surprises due to legal regulations).
• Handover of documents and access: Explicitly agree which documents, data and accesses the developer must hand over to the client. Keywords such as “source code”, “configuration data”, “documentation”, “access data” etc. should appear in a no-code contract. For example: Admin access to the Webflow instance, API key, description of all workflows in Azure Logic Apps (copyright to the workflows remains with the developer, but the client receives a right of use – see Azure Logic Apps copyright), export of database structures from Airtable, etc. Depending on the platform, this can be very individual. It is important that both sides know what the client is entitled to after the end of the project. In this way, you avoid the situation “source code release no-code” – where the client realizes that there is no traditional code and nothing is contractually provided for.
• Regulate rights of use comprehensively but precisely: Make sure that the contract contains a rights of use clause that addresses the specifics. As a minimum, the client should receive the right to use the created solution for an unlimited period of time and territory in order to operate it to the intended extent. If desired, agree exclusive rights to the individual parts so that the client is, for example, the only person allowed to use this specific combination or solution. At the same time, the contract should state that platform and third-party components cannot be transferred by the developer. This makes it clear, for example, that the client may use the finished Webflow website, but of course does not acquire any rights to the Webflow software or general templates. Such clauses may seem obvious, but in the event of a dispute (and also in the customer’s perception) they are worth their weight in gold. Terms such as “Rights of use software development” or “Exclusive right of use” can be used as headings in the contract so that the meaning is clear.
• Third-party providers, APIs and obligations to cooperate: No-code solutions thrive on integrations – be it the integration of a payment provider via API, the use of external databases or SaaS services (CRM, email, etc.). The contract should regulate who is responsible for these third-party services. Does the client have to provide their own licenses/subscriptions for Airtable, Webflow & Co. Does he bear the costs directly? Or does the developer take care of this and charge for it? Who is liable if an external service fails or changes its API policies (keyword: Webflow API law – e.g. if Webflow restricts API usage, the developer should not be liable for this without being checked)? In addition, the client is often obliged to help, for example by setting up accounts or providing access to their Azure portal. Such obligations to cooperate should be included in the contract. A clause on changes to the platform should also be included: If the no-code platform is updated or functions are discontinued during the term of the contract, it must be clear whether the developer is obliged to make improvements free of charge or whether this constitutes a new order.
• Adjust warranty and liability: Standard IT contracts contain warranty provisions for software (rectification of defects, etc.). With no-code, you have to bear in mind that some problems could come from the platform. For example, a bug in the Airtable software itself or a change in Azure Logic Apps that breaks a flow – the developer is usually not responsible for this. The contract should address such cases in the liability (such as force majeure or exclusion of liability for circumstances beyond the developer’s control). In addition, the warranty period for work services should be defined, but in the case of permanent services, service contract law applies instead of warranty (i.e. only liability for poor performance). Also clarify whether the developer is liable for defects of title – for example, if he uses open source components, he must ensure that these do not “contaminate” the software (keyword: copyleft licenses).
• No blind adoption of model clauses: No-code projects differ considerably from traditional software projects in some respects. Standard clauses from a conventional IT contract often do not cover important special features. Example: A standard contract template could stipulate that the developer hands over “all source code, builds and documentation” at the end. Anyone who has only worked with construction kits is then faced with the question: Do I even have a “build”? What if parts of the application cannot be exported at all because they have to remain in the cloud? Conversely, a sample contract might not deal with the topic of ongoing maintenance at all, even though it was actually agreed – a risk, because then the legal regulations apply by default, which may not fit (e.g. a judge could classify the whole thing as a service contract, even though the text was not clear). Also be careful with translations: Some use English templates, but terms such as “license” or “work made for hire” have other equivalents in German law. Conclusion: A contract for a no-code/low-code project should not be put together using the copy-paste method. It is better to adapt it specifically or – even better – have it drafted by an expert from the outset.

Why professional advice? The above information shows: A supposedly “simple” no-code project raises similarly complex legal issues as a classic software project, in some cases even new ones. The technical structure (modular system, SaaS, APIs) must be reflected in the contractual structure. Start-ups and agencies run the risk of overlooking important points, precisely because no-code tools abstract many things. The experience of an IT lawyer who understands both the legal intricacies and the technical realities of no-code/low-code stacks is extremely valuable here. This is the only way to create contracts that protect both sides, safeguard the commercial objectives and are legally valid.

Conclusion

Developing software on no-code platforms such as Airtable, Webflow, AWS Honeycode or Azure Logic Apps is a game changer for fast results – but not a free pass to ignore the law. On the contrary: because the technology is different, contracts need to take an even closer look. Whether it’s the correct classification of maintenance contracts (service vs. work contract), the release of source code or configurations, the rights to use the software or practical contract details – every detail counts to make a no-code contract truly legally secure. If you take all of this into account, you protect yourself from unpleasant surprises and lay the foundation for a trusting collaboration between client and service provider.

Start-ups, agencies and IT project managers in particular should take the pitfalls described above seriously. An unclear contract can cost a lot of money, time and nerves in retrospect – for example if an investor asks who actually owns the rights to the developed app, or if the developer is suddenly no longer available and you realize that you have no access to important components. Lawyers for IT law with experience in SaaS and digital platform projects can be valuable companions here: they know the relevant case law (from BGH X ZR 6/00 to LG Cologne “Flatrate-SEO”), they understand terms such as “transfer of purpose rule” and API license terms, and they also know technically what it means when a Webflow website is exported or a script is stored in Airtable.

In short, a legally compliant software contract for no-code projects combines legal precision with an understanding of the low-code world. This allows innovative companies to take full advantage of the benefits of no-code without being on thin legal ice. The effort invested in drafting a clean contract pays off in the end – and in case of doubt, a specialized lawyer is on hand to offer precisely this added value. Because no-code or not: you shouldn’t risk a “no-law” when it comes to contracts.