No-code and low-code platforms enable start-ups and agencies to develop software and digital products quickly, often without in-depth programming knowledge. However, when software development uses SaaS services and no-code tools like Airtable, Webflow, AWS Honeycode, or Azure Logic Apps, significant legal issues arise. A no-code contract must be drafted as carefully as a traditional software contract to ensure it is legally secure.

Otherwise, risks emerge, ranging from unclear performance obligations and disputes over source code distribution to gaps in usage rights. This article highlights the most important aspects: How should maintenance contracts be classified in the context 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? Additionally, which practical clauses are essential for any "no-code SaaS law" contract?

This overview explains crucial considerations and underlines why legally compliant software contracts in this area require professional advice.

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).

A service contract means the service provider owes an action (i.e., efforts) but no specific success. Conversely, a contract for work means a specific result is owed (a "work") that the client can accept. This includes, for example, a fully programmed application meeting certain requirements.

This distinction has significant consequences. For a contract for work and services, warranty rights and acceptance apply, and the client may terminate the contract before completion (Section 648 BGB). With a service contract, however, "pacta sunt servanda" applies. The contract generally runs for the agreed duration, with no entitlement to a specific result, only to diligent action.

Legal Classification of Maintenance Contracts

Maintenance contracts in the no-code environment, such as for 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 offer availability and monitoring-related services. These services include regular monitoring, installing updates, fixing bugs, or guaranteeing a certain response time in the event of an error.

This raises a crucial question: Is this a service contract or a contract for work? Case law tends to classify such flat-rate agreements as service contracts. For instance, the Regional Court of Cologne ruled that a comprehensive agency agreement with a monthly flat fee is a contract for services (judgment of 20.02.2015 – Ref. 12 O 186/13, "Internet agency flat rate").

Although individual elements (like the one-off creation of a website) had the character of work, the ongoing marketing and SEO services, being open-ended activities, predominated. The main reasons for classification as a service contract were:

The agreement was designed as a long-term continuing obligation.
Remuneration was owed regardless of a single success.
The focus was on the ongoing availability of services when required, not on producing a one-off end product.

This applies equally to maintenance contracts for no-code software. The contractor remains ready and provides services as required, which do not always result in a tangible "work."

Practical Implications for Contract Type

In practice, this means: clarify the type of contract! If ongoing support for a no-code application has been agreed, it should be expressly stipulated that it is a service contract, if that is the intention. This 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. This could be done in different parts of the contract or even separate agreements, such as a development contract followed by a maintenance contract. This avoids confusion regarding which legal rules apply.

Flat-Rate Remuneration and Service Verifiability

A particular problem with flat-rate maintenance contracts is the verifiability of services. Often, the client can hardly see what the service provider is doing in the background. This is especially true if there are few faults; for example, the service provider receives a monthly flat fee for "monitoring" a no-code app, but the app runs stably, requiring no interventions. Nevertheless, the remuneration is owed, as the service here consists of the service provider's readiness and availability.

Legally, this is justified by the nature of the agreement and its character as a service contract. The contractor provides 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 Cologne Regional Court case mentioned earlier, the court argued that the monthly fee was to be paid "regardless of the services actually provided" and that the constant readiness to work was being compensated.

From the perspective of good faith (Section 242 BGB), a contractor should nonetheless ensure transparency. Reporting obligations in the contract are recommended, such as a monthly report on tests, updates, or backups. This shows the client that the service provider has been active, maintaining trust. It also prevents later disputes about whether "nothing was done," as both sides understand the invisible tasks performed.

To summarize: For maintenance contracts in the no-code area, there is a strong case for classifying them as a service contract. This should be explicitly stated in the contract, and the scope of owed activities (readiness, monitoring, troubleshooting, etc.) precisely described. Flat-rate remuneration for readiness is common.

However, mechanisms should be agreed upon for handling additional services. If complex activities not originally covered arise, a remuneration adjustment, as per new concept of defects for software development, may be considered. The Federal Court of Justice ruled that even in a flat-rate contract for work and services, the contractor can demand additional remuneration if the customer requested significant additional services not originally planned (judgment of January 8, 2002 – case no. X ZR 6/00).

Applied to maintenance contracts, this means that if additional development tasks, far beyond monitoring, are undertaken as part of a lump sum, it should be contractually clarified whether these are to be remunerated separately. Clear regulations and a distinct separation of the basic flat rate and additional services prevent unexpected disputes. Otherwise, Section 242 BGB (good faith) might be used as a loophole for a fair balancing of interests, leading to unnecessary legal uncertainty.

Publication of Source Code or Functional Equivalents for No-Code Projects

Start-ups and IT project managers particularly value access to the "blueprint" – traditionally the source code – beyond just a running product. This issue is especially relevant for no-code platforms, where conventional source code is often absent. Applications might consist of graphically configured workflows, databases, or proprietary modules. So, what happens when a customer demands the "source code or something equivalent"?

Traditional Software Development vs. No-Code

First, let's examine the legal situation and case law for classic software development. Whether a client is entitled to the release of the source code depends on the general interpretation of the contract and copyright law, absent specific regulation. According to Sections 133, 157 BGB, a contract is interpreted as required by good faith, considering common usage; essentially, what did the parties objectively agree upon?

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, they extend only to what is necessary to achieve the contract's purpose. For software, this means the client generally receives rights to use the program as agreed, but nothing more, unless expressly stipulated otherwise.

In its case law, the Federal Court of Justice has developed groups of cases determining when a source code disclosure claim exists (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. Courts argue that the customer can use the software without the source code, and the contract's purpose (use of the standard solution) does not require its handover. The Higher Regional Court of Munich ruled in 1991 that source code does not have to be supplied with standard software unless otherwise agreed (case no. 25 U 2586/91).
Individual software: If individual software (developed specifically for the customer) was commissioned, it depends on individual circumstances. The BGH requires a balancing of interests, asking whether the intended use of the software requires knowledge of the source code. The principle is: no claim for surrender if the program can be used without the source code. The client can use the finished program without further self-development, which is likely the contract's purpose unless otherwise agreed.
Exception – foreseeable need for changes: Only if it was apparent to the programmer (or 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 is when the client made it clear they need the source code to develop the software themselves or commission another developer for updates. If such a purpose was a recognizable part of the contract, the source code is part of the owed performance, and the developer must hand it over (as generally understood from BGH X ZR 129/01).
No claim during ongoing maintenance: In its ruling of January 30, 1986 (case no. I ZR 242/83), the BGH clarified that the client has no claim to the surrender of the source code during the term of a maintenance or support contract. As long as the original developer is contractually obliged to maintain the software, there is no need to entrust a third party with further development. 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.

Functional Equivalents in No-Code

Applied to no-code platforms, this means that even without classic source code, 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 have source code and object code. For an Airtable solution, this could be the basic configuration, formulas, scripts, or automations set up by the developer. For Webflow, it might be the exported HTML/CSS/JS code of the website, as well as access to the Webflow instance or CMS.

In Azure Logic Apps or AWS Honeycode, it could be workflow definitions, JSON exports, or other description files representing the developed logic. The term "functional equivalent" aims to provide the client with tools to independently use, reproduce, or modify the developed application if needed, even if handwritten source code is absent.

Contract Interpretation and Practical Tip

Absent an express agreement, case law often dictates no claim for surrender as long as the customer can use the no-code solution. For example, if a start-up commissions an agency to create a complex Airtable database with automation, and the contract says nothing about handing over "files" or configurations, the start-up later demands settings or export data from the original developer to commission another service provider. Does it have a legal claim? Probably not.

According to Section 31 (5) UrhG, the client likely only received the necessary rights of use to operate the Airtable base, and they probably have user access anyway. The configuration as such (which may be copyrighted software or database work) likely remains with the developer. Without an agreement, the developer could argue, "You can use the Airtable base as intended; I owe you nothing more." Similarly, with Webflow, if the contract only requires providing the current website, the developer doesn't have to provide editor access or design exports without a special agreement, as long as the website is accessible and usable as agreed.

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 created application. This includes, in particular, [list: e.g., export of project files, documentation of workflows, administrator access to platform XYZ, API documentation, etc.]."

A software escrow contract or escrow agreement is also helpful, even in a no-code context. For example, it could be agreed that configuration data or designs are deposited with a notary or in an escrow account, accessible to the customer if the developer becomes unavailable. In practice, the procedure is often simpler: the source code might initially remain with the service provider, but with an agreement that the service provider must hand it over to the client or a nominated third party upon request. Such clauses translate judicial ambiguity into clear contractual rights.

For no-code SaaS projects, it's also important that the operation of the application is often tied to an account. It makes sense to stipulate that the created application is transferred to a client's account or that the client receives administrator rights to it. For example, a Webflow website can be transferred to the customer's account, or the customer can be made the owner of an Airtable base. Contracts should stipulate that the service provider hands over full control at the end of the development phase, ensuring the client isn't trapped when the business relationship ends.

To summarize: "Source code handover" in a no-code context is a tricky issue requiring proactive contractual resolution. Without a clear agreement, the principle of purpose transfer applies, and the customer often receives less than intended (only usage, not the blueprints). Start-ups should ensure their no-code contract includes clauses on the documentation and handover of important components. Otherwise, they might face a locked system when changing developers.

From the developer's or agency's perspective, it's legitimate to include protective mechanisms, such as releasing components only after full payment or retaining proprietary secrets. Both sides must have a clear, common understanding of what will be delivered at the contract's end—whether it's source code, configuration data, or at least assurance of access to all essentials.

Scope of Rights of Use: Individual Software vs. Platform Components in No-Code Applications

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 typically receives a right to use the created program. This right can be simple (non-exclusive) or exclusive, unlimited geographically and temporally, or with specific restrictions, depending on the agreement.

With no-code projects, the situation is more complex due to the combination of two levels:

Individually created components: These include specific workflows, automations, designs, databases, or other creative elements developed by the contractor for the project. These can be protected by copyright, for example, as a computer program (Section 69a UrhG), a database work (Section 4 (2) UrhG), or even a design, if it reaches a creative level. The developer can grant the client usage rights to these parts.
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 providers. Neither the developer nor the client "own" the platform's source code. They only have rights of use by virtue of the contract with the platform provider, usually as a SaaS subscription. Additionally, open source libraries or engine components, whose rights are held by third parties, are often used in the background.

Exclusive Rights and Platform Restrictions

Obtaining exclusive rights of use for software means the client may use and exploit the software to the exclusion of all others. Even the developer may not use it elsewhere without further agreement. In individual software development for a single customer, granting exclusive rights of use to the specifically developed code is common. After all, clients pay for it and may wish to exclude competitors.

In the no-code area, however, a clear distinction must be made regarding what can be exclusively transferred. The developer can only transfer rights to which they themselves are entitled. The developer has no rights to the underlying platform (e.g., Airtable software or Webflow engine) that they could pass on. Only the platform provider holds copyrights here. Consequently, the customer only receives these services for use within the scope of the platform license.

Practically, this means a client receives the right to use, edit, and publish the created Webflow website, but does not acquire any rights to the Webflow software itself. Similarly with Azure Logic Apps: the workflow configured by a service provider for the customer may be creative, but the customer can only access it within Microsoft's Azure platform. Copyright-wise, whether the specific workflow as a computer program belongs to the service provider could be debated. Even if it does, the customer primarily needs permission to operate it on Azure. Microsoft's SaaS contract ensures this, either with the customer or the service provider, depending on the arrangement.

License Models and Exclusion Clauses

In the IT industry, it is common to structure contracts so that the client receives all necessary rights of use to the deliverables, but the developer excludes certain general rights or third-party components. For example, a clause often states that the client receives an exclusive right to use the individual software, but without 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: "The client receives the exclusive, temporally and geographically unrestricted right of use for all known types of use for the individually provided work results (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."

This arrangement ensures the customer has full control over the results of the commissioned development (they can use, modify, sublicense, etc., concerning the individual service). Simultaneously, it protects the developer from unintentionally losing general solutions or templates and safeguards the rights holders of third parties. The no-code agreement should explicitly state that platform components and any integrated services are not part of the rights transfer.

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 their respective terms of use. This is also important for license agreements for software start-ups.

Open Source and Engine Components

A similar situation exists in game development. If a studio develops a game using a game engine (like Unity or Unreal), the publisher cannot claim the engine rights from the studio, as these belong to Unity/Unreal. Similarly, with no-code, the "engine" or framework components are not exclusively available. Open source modules are often used in no-code platforms (e.g., a JavaScript library in Webflow export). The respective open source license automatically applies: the client may use these components but must comply with license conditions (e.g., naming license texts, no exclusive use).

A legally compliant software contract will consider these points. It is beneficial to mention in the contract that certain software components are open source and under which license, informing the client of their permissible actions (e.g., not reselling a component commercially if the license prohibits it).

To summarize: The scope of usage rights should be very clearly described in no-code development contracts. The client wants to ensure they receive the necessary rights to all individual results, preferably exclusively, to freely use and further develop the solution. At the same time, they must accept that the underlying infrastructure and generic modules cannot belong to them. Therefore, it is crucial to differentiate between individual software and platform components in the contract. This clarifies what the customer pays for (and acquires ownership/rights of use) and what falls outside this area.

Without such clarification, conflicts can arise: either the customer feels deceived, believing "everything belongs to them," or the developer fears their know-how is at risk. Precise license clauses and industry-standard exclusions can prevent this.

Practical Tips for No-Code Contracts

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

Clarify the Scope of Services and Contract Type: Describe precisely 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 work services requiring acceptance (e.g., initial application creation until Go-Live) and which are service components of a continuing obligation (e.g., subsequent support, SEO, or hosting). This clarifies from the outset whether it is a no-code contract for work, a service contract, or a mixed contract. For mixed forms, define the focus or separate services to prevent disputes over termination rights and remuneration.
Remuneration, Term, and Termination: For flat-rate remuneration models, ensure transparency about 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 handled—for instance, an hourly or daily rate for requirements 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. However, remember that if it's a service contract, ordinary termination during the term is generally excluded unless contractually provided for. Contracts for work and services can be terminated by the client at any time (Section 648 BGB), posing a financial risk for the service provider. Coordinate the contract model and termination clauses to avoid unwanted loopholes or surprises from legal regulations.
Handover of Documents and Access: Explicitly agree on which documents, data, and accesses the developer must hand over to the client. Keywords such as "source code", "configuration data", "documentation", "access data" should appear in a no-code contract. Examples include: 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 crucial that both sides know what the client is entitled to after the project ends. This avoids the situation of "source code release no-code," where the client realizes there is no traditional code and nothing is contractually provided.
Regulate Rights of Use Comprehensively but Precisely: Ensure the contract contains a rights of use clause addressing the specifics. At a minimum, the client should receive the right to use the created solution for an unlimited period and territory to operate it to the intended extent. If desired, agree on exclusive rights to the individual parts, so the client is, for example, the only one permitted to use this specific combination or solution. Simultaneously, the contract should state that platform and third-party components cannot be transferred by the developer. This clarifies that the client may use the finished Webflow website but does not acquire rights to the Webflow software or general templates. Such clauses may seem obvious but are invaluable in disputes and for customer perception. Terms like "Rights of use software development" or "Exclusive right of use" can be used as headings for clarity.
Third-Party Providers, APIs, and Cooperation Obligations: No-code solutions thrive on integrations, whether it's payment provider integration via API, external database usage, or SaaS services (CRM, email, etc.). The contract should regulate responsibility for these third-party services. Does the client provide their own licenses/subscriptions for Airtable, Webflow, etc., and bear the costs directly? Or does the developer manage this and charge for it? Who is liable if an external service fails or changes its API policies (e.g., if Webflow restricts API usage, the developer should not be liable without a check)? Clients are often obliged to cooperate, such as setting up accounts or providing Azure portal access. Such obligations to cooperate should be in the contract. A clause on platform changes is also essential: if the no-code platform updates or discontinues functions during the contract term, it must be clear whether the developer is obliged to make free improvements or if this constitutes a new order.
Adjust Warranty and Liability: Standard IT contracts contain warranty provisions for software (rectification of defects, etc.). With no-code, some problems might originate from the platform itself. For example, a bug in the Airtable software or an Azure Logic Apps change that breaks a flow—the developer is usually not responsible. The contract should address such cases in the liability section (e.g., force majeure or exclusion of liability for circumstances beyond the developer's control). Additionally, define the warranty period for work services. For permanent services, service contract law applies instead of warranty (i.e., only liability for poor performance). Also clarify if the developer is liable for defects of title—for example, if they use open source components, they must ensure these do not "contaminate" the software (keyword: copyleft licenses).
No Blind Adoption of Model Clauses: No-code projects differ significantly from traditional software projects in some respects. Standard clauses from conventional IT contracts often do not cover important special features. For instance, a standard contract template might stipulate that the developer hands over "all source code, builds, and documentation" at the end. Someone who only worked with building blocks then faces the question: Do I even have a "build"? What if parts of the application cannot be exported because they must remain in the cloud? Conversely, a sample contract might not address ongoing maintenance, even if agreed—a risk, as default legal regulations might not fit (e.g., a judge could classify it as a service contract, even if the text was unclear). Be cautious with translations: English terms like "license" or "work made for hire" have different equivalents in German law. Conclusion: A contract for a no-code/low-code project should not be assembled via copy-paste. It is better to adapt it specifically or, even better, have an expert draft it from the outset.

Why Professional Legal Advice for No-Code Contracts is Essential

The information above demonstrates that a supposedly "simple" no-code project raises complex legal issues, sometimes even new ones, similar to classic software projects. The technical structure (modular system, SaaS, APIs) must be reflected in the contractual structure. Start-ups and agencies risk overlooking important points precisely because no-code tools abstract many aspects. 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 commercial objectives, and are legally valid.

Conclusion

Developing software on no-code platforms like Airtable, Webflow, AWS Honeycode, or Azure Logic Apps is a game-changer for rapid results, but it does not mean ignoring legal requirements. On the contrary, because the technology is different, contracts need even closer scrutiny. 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 element is crucial for a no-code contract to be truly legally secure. Addressing these points protects you from unpleasant surprises and lays the foundation for a trusting collaboration between client and service provider.

Start-ups, agencies, and IT project managers should take the pitfalls described above seriously. An unclear contract can retrospectively cost significant money, time, and nerves. For instance, if an investor questions the ownership of software rights for a developed app, or if the developer is suddenly unavailable and you lack access to critical components. Legally compliant software contracts in IT law, with experience in SaaS and digital platform projects, can be invaluable. They are familiar with relevant case law, understand terms like "transfer of purpose rule" and API license terms, and technically grasp what it means to export a Webflow website or store a script 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 enables innovative companies to leverage the benefits of no-code without being on thin legal ice. The effort invested in drafting a clean contract pays off. In case of doubt, a specialized lawyer provides this added value. Because no-code or not, you should never risk a "no-law" approach when it comes to contracts.