No-Code-/Low-Code-Verträge: Rechtssicher entwickeln | IT-Medienrecht

No-Code- und Low-Code-Plattformen ermöglichen die schnelle Softwareentwicklung ohne umfangreiche manuelle Programmierung. Immer häufiger werden Anwendungen auf Basis von Tools wie Bubble, Webflow, Airtable oder Auth0 entwickelt, um Zeit und Kosten zu sparen. Doch diese modernen Ansätze bringen besondere vertragliche Herausforderungen mit sich.

Auftraggeber und Entwickler müssen sich sensibilisieren, denn ein No-Code-Vertrag muss ebenso sorgfältig gestaltet sein wie ein klassischer IT-Vertrag. Andernfalls drohen Risiken wie unklare Leistungspflichten, Streit um fehlenden Quellcode, Abhängigkeiten von Drittplattformen oder Lücken bei den Nutzungsrechten. Solche Unklarheiten können zu erheblichen Konflikten führen. Um diese zu vermeiden, beleuchten wir im Folgenden die wichtigsten Punkte. Ziel ist es, dass Verträge für No-Code-/Low-Code-Softwareentwicklung professionell und rechtssicher gestaltet werden können – neutral und fundiert aus juristischer Sicht. Die Relevanz einer durchdachten Vertragsgestaltung unterstreicht auch unser Artikel Warum sind Verträge wichtig?.

Besondere Vertragsklauseln bei No-Code-/Low-Code-Entwicklung

Wird Software ganz oder teilweise mit No-Code-/Low-Code-Tools erstellt, sollten Verträge spezifische Klauseln enthalten. Diese gehen über Standard-Softwareverträge hinaus. Ein klar definierter Leistungsumfang ist dabei essenziell: Was schuldet der Entwickler genau?

Bei traditionellen Projekten wird häufig die Lieferung von Quellcode und einer installierbaren Software geschuldet. Bei No-Code-Projekten gibt es oft keinen klassischen Quellcode, sondern eine konfigurierte Anwendung auf einer Plattform. Daher muss vertraglich festgelegt werden, was als Endergebnis gilt. Dies kann zum Beispiel die funktionsfähige Anwendung auf der gewählten Plattform inklusive aller Workflows, Einstellungen und erforderlichen Zugänge sein.

Nutzungs- und Eigentumsrechte präzise regeln

Zudem sind Nutzungs- und Eigentumsrechte ausdrücklich zu regeln. Der Auftraggeber muss das Recht erhalten, die entwickelte No-Code-Anwendung wie vorgesehen zu nutzen. Bei Bedarf kann dies auch exklusiv vereinbart werden.

Gleichzeitig ist klarzustellen, dass Rechte an der No-Code-Plattform selbst oder an vorgefertigten Bausteinen nicht übergehen. Der Kunde erwirbt also kein Eigentum am Tool oder den Standard-Modulen, sondern nur an den individuell erstellten Komponenten der Anwendung. Nutzt ein Kunde beispielsweise eine auf Webflow erstellte Website, darf er diese nutzen und inhaltlich verändern. Rechte an der Webflow-Software oder allgemeinen Design-Templates der Plattform erwirbt er jedoch nicht. Solche Klauseln mögen selbstverständlich klingen, sind im Streitfall aber von großem Wert. Die rechtliche Klarheit bei der Rechteübertragung ist auch ein zentrales Thema, wie unser Beitrag zur Rechtekette im Game Development aufzeigt.

Drittanbieter und Integrationen: Wer zahlt, wer haftet?

Ein weiterer wichtiger Vertragsbestandteil sind Regelungen zu Drittanbietern und Integrationen. No-Code-/Low-Code-Lösungen binden oft externe Dienste ein, etwa Zahlungsanbieter per API, Cloud-Datenbanken oder andere SaaS-Dienste. Der Vertrag sollte klären, wer für diese Drittleistungen verantwortlich ist und wer die Kosten trägt.

Muss der Auftraggeber beispielsweise eigene Lizenzen oder Abonnements für Airtable, Webflow & Co. bereitstellen? Trägt er die Gebühren direkt oder beschafft der Entwickler die Accounts und stellt sie dem Kunden in Rechnung? Solche Finanzierungs- und Mitwirkungspflichten des Auftraggebers gehören ausdrücklich in den Vertrag (siehe § 642 BGB zur Mitwirkungspflicht des Bestellers). Zudem ist festzuhalten, dass der Entwickler nicht für die Leistung externer Dienste einzustehen hat, sofern nicht anders vereinbart.

Beispiel: Wird ein E-Mail-Dienst angebunden und dieser fällt aus, darf der Entwickler dafür nicht ungeprüft haften müssen. Auch die vertraglichen Besonderheiten bei Cloud-Modellen sind hierbei relevant.

Praxis-Tipp: Kontrolle beim Auftraggeber sichern

Häufig ist es sinnvoll, dass der Auftraggeber frühzeitig eigene Accounts bei den benötigten No-Code-Plattformen einrichtet. Alternativ kann er dem Entwickler Zugang zu seinem Konto gewähren. So bleibt die Kontrolle beim Kunden, und die fertige Anwendung kann am Vertragsende leicht übertragen werden.

Verträge sollten verbindlich vorsehen, dass die erstellte Anwendung schließlich auf einen Account des Auftraggebers übertragen wird oder dieser zumindest volle Administratorrechte erhält. Damit steht der Kunde nicht vor verschlossenen Türen, wenn die Geschäftsbeziehung endet.

Aufklärungspflichten des Entwicklers über Grenzen und Risiken

Eine zentrale Frage ist, ob den Entwickler eine Aufklärungspflicht trifft, den Kunden über die Grenzen, Risiken und Abhängigkeiten von Drittplattformen zu informieren. Grundsätzlich gilt: Jeder Vertragspartner muss auf die Rechte, Rechtsgüter und Interessen des anderen Teils Rücksicht nehmen (§ 241 Abs. 2 BGB).

Daraus erwächst im Projektkontext eine Beratungs- und Hinweispflicht des Softwareentwicklers. Er darf nicht schweigen, wenn er erkennt, dass bestimmte Kundenanforderungen mit der gewählten No-Code-/Low-Code-Lösung nicht erfüllbar sind oder wenn erhebliche Risiken bestehen (etwa Abhängigkeit von einer Cloud-Plattform). Der Umfang dieser Beratungspflicht richtet sich nach den Umständen, insbesondere nach der Sachkunde des Auftraggebers. Bei einem technisch unerfahrenen Kunden muss der Entwickler umfassender warnen; bei einem sehr fachkundigen Kunden können geringere Erläuterungen vorausgesetzt werden.

Konkrete Hinweise zu Grenzen und Risiken

Konkret bedeutet das: Der Entwickler muss den Auftraggeber vor Vertragsschluss und während der Umsetzung auf wesentliche Grenzen der No-Code-Tools hinweisen. Wenn eine gewünschte Funktionalität mit der Plattform nicht umsetzbar ist oder nur mit Workarounds, muss der Kunde dies frühzeitig erfahren. Ebenso sind Risiken wie Skalierungsgrenzen (z. B. maximale Nutzerzahlen oder Datenmengen) offenzulegen.

Auch die Gefahr eines Vendor Lock-ins – die Abhängigkeit von einem einzigen Anbieter – gehört angesprochen. No-Code-Lösungen beruhen oft auf proprietären Systemen. Der Kunde sollte wissen, dass ein Plattformwechsel später mit erheblichem Aufwand verbunden sein kann.

Beispiel aus der Praxis: Fehlende Aufklärung

Beispiel: Eine Agentur schlägt einem Start-up vor, dessen Applikation komplett auf einer No-Code-Plattform zu entwickeln, da dies schneller geht. Die Agentur ist sich aber bewusst, dass die Plattform bestimmte Datenschutzanforderungen des europäischen Marktes nicht voll erfüllt und bei hohem Nutzeraufkommen Performance-Probleme auftreten könnten. Hier ist sie verpflichtet, den Kunden über diese Punkte aufzuklären.

Unterlässt sie dies, könnte sie sich schadensersatzpflichtig machen – zum Beispiel wegen Verletzung vorvertraglicher Pflichten (Stichwort culpa in contrahendo) oder Nebenpflichten aus dem Vertrag. Im deutschen Werkvertragsrecht wird dem Entwickler sogar ein Mitverschulden (§ 254 BGB) angerechnet, wenn er erkennbare Fehler im Konzept des Auftraggebers nicht anspricht. Transparenz von Anfang an schützt beide Seiten.

Abhängigkeiten von Drittanbietern

Zusätzlich umfasst die Aufklärungspflicht auch den Hinweis auf Abhängigkeiten von Drittanbietern. Der Kunde sollte verstehen, dass seine fertig entwickelte Anwendung letztlich nur so stabil und verfügbar ist, wie es die zugrunde liegende Plattform erlaubt. Gibt es bekannte Einschränkungen (z. B. bestimmte API-Limits oder fehlende Offline-Möglichkeiten), sollte der Entwickler dies klar benennen.

Gegebenenfalls muss der Entwickler auch Alternativen aufzeigen (etwa: „Funktion X geht mit diesem No-Code-Tool nicht – dafür bräuchte man eine Individualentwicklung oder ein zusätzliches Plugin“). Nur so kann der Auftraggeber eine informierte Entscheidung treffen. Diese Beratung sollte idealerweise schriftlich dokumentiert oder im Vertrag festgehalten werden, um späteren Streit zu vermeiden.

Haftung bei Ausfall oder Wegfall von No-Code-Plattformen

Ein besonderes Risiko bei Softwareentwicklung mit No-Code/Low-Code ist die Abhängigkeit von der Verfügbarkeit und Stabilität der verwendeten Plattform. Was passiert, wenn Dienste wie Bubble, Webflow, Airtable oder Auth0 ausfallen, zeitweise eingeschränkt sind oder im schlimmsten Fall ihren Betrieb einstellen? Vertraglich muss klar verteilt werden, wer in solchen Fällen welches Risiko trägt.

Haftungsbeschränkung für externe Einflüsse

Grundsätzlich schuldet der Entwickler die vertraglich vereinbarte Leistung, also zum Beispiel die Erstellung einer funktionierenden Anwendung auf der gewählten Plattform. Er schuldet aber in der Regel nicht den fortwährenden Betrieb der Plattform selbst – dafür ist der Plattformanbieter verantwortlich.

Daher sollte im Vertrag eine Haftungsbeschränkung vorgesehen sein. Diese stellt den Entwickler von der Haftung für Umstände frei, die außerhalb seiner Kontrolle liegen (vgl. § 276 Abs. 1 BGB zur Verantwortlichkeit). Eine solche Klausel könnte Ausfälle oder Leistungsminderungen der zugrundeliegenden SaaS-Plattform als höhere Gewalt oder als vom Entwickler nicht zu vertretende Umstände definieren. Dadurch kann klargestellt werden, dass externe Ereignisse keine Vertragsverletzung durch den Entwickler darstellen.

Beispiel: Die vom Entwickler erstellte Business-App läuft vollständig auf Airtable. Eines Tages hat Airtable einen großflächigen Ausfall oder ändert seine API, wodurch Teile der App nicht mehr funktionieren. Ohne vertragliche Regelung könnte der Auftraggeber versuchen, den Entwickler wegen eines Mangels oder Ausfalls in Anspruch zu nehmen. Mit einer passenden Vertragsklausel hingegen wird deutlich: Solange der Entwickler den Fehler nicht zu vertreten hat, haftet er hierfür nicht. Stattdessen wäre es ein Fall für den Support des Plattformanbieters oder ein gemeinsames Krisenmanagement, bei dem der Entwickler gegen zusätzliche Vergütung bei der Fehlersuche unterstützt. Dies ähnelt den Herausforderungen bei der Mangelhaftigkeit von SaaS-Lösungen.

Umgang mit dem Wegfall einer Plattform

Neben technischen Ausfällen ist auch der Wegfall der Plattform insgesamt zu bedenken. No-Code-Plattformen können ihre Geschäftsmodelle ändern, drastische Preiserhöhungen vornehmen oder sogar eingestellt werden. Hier sollte vertraglich zumindest festgehalten werden, dass ein solcher Wegfall als Änderung der Geschäftsgrundlage gesehen werden kann.

Gegebenenfalls können die Parteien vereinbaren, in einem solchen Fall neu zu verhandeln. Es könnte auch ein Sonderkündigungsrecht für den Auftraggeber bestehen, wenn die Grundlage des Projekts (die verfügbare Plattform) entfällt. Der Entwickler wird in der Regel nicht garantieren können, dass eine Plattform auf ewig existiert oder unverändert bleibt – dieser unternehmerische Risikoanteil liegt faktisch beim Auftraggeber, der sich für den No-Code-Weg entschieden hat. Allerdings kann der Entwickler unterstützen, indem er beispielsweise Alternativszenarien aufzeigt (Migration auf eine andere Plattform, Export der Daten etc.).

Anpassung von Haftung und Gewährleistung

In jedem Fall ist es ratsam, Haftung und Gewährleistung an die Besonderheiten anzupassen. In klassischen Softwareverträgen gibt es Gewährleistungsfristen für Mängel und oft weitgehende Haftungsausschlüsse für Folgeschäden. Im No-Code-Kontext sollte die Gewährleistung klar darauf begrenzt werden, dass die erstellte Anwendung zum Zeitpunkt der Abnahme vertragsgemäß funktioniert.

Spätere Änderungen oder Ausfälle der Plattform wären kein Mangel der Werkleistung, sondern eben Änderungen der Umgebung. Eine Haftung des Entwicklers kann hier vertraglich ausgeschlossen oder auf Fälle von Vorsatz und grober Fahrlässigkeit beschränkt werden (wobei solche Haftungsbeschränkungen in AGB sorgfältig formuliert sein müssen, um nicht gegen § 307 BGB zu verstoßen). Unberührt bleiben müssen natürlich zwingende Haftungen, etwa für Personenschäden – diese bestehen im reinen Softwarebereich aber selten. Beide Seiten sollten die Haftungsregelungen genau prüfen, damit im Ernstfall klar ist, wer welchen Schaden zu tragen hat.

Rechteübertragung und fehlende Quellcode-Herausgabe

Bei herkömmlicher Softwareentwicklung wird im Vertrag meist die Übertragung der urheberrechtlichen Nutzungsrechte an der Software vereinbart. Dies ist oft mit der Herausgabe des Quellcodes an den Auftraggeber verbunden. Im No-Code-/Low-Code-Bereich stellt sich dies schwieriger dar: Häufig gibt es keinen umfassenden Quellcode, den man übergeben könnte, da die Anwendung aus grafischen Workflows, Konfigurationen und proprietären Modulen besteht. Dennoch müssen die Rechte an den Arbeitsergebnissen geregelt werden.

Nutzungsrechte an individuell erstellten Bestandteilen

Zunächst ist festzulegen, dass der Auftraggeber alle erforderlichen Nutzungsrechte an den individuell erstellten Bestandteilen der Anwendung erhält. Alles, was der Entwickler eigenständig geschaffen hat – sei es ein spezifisches Workflow-Design, eigene Skripte innerhalb der Plattform oder eine besondere Zusammenstellung von Modulen – sollte der Kunde nutzen, bearbeiten und (wenn vereinbart) exklusiv verwenden dürfen.

Rechtlich gesehen entsteht an solchen schöpferischen Leistungen ein Urheberrecht des Entwicklers (§ 69a Abs. 3 UrhG für Software und allgemeiner § 2 UrhG). Ohne vertragliche Vereinbarung bliebe dieses beim Entwickler, und der Kunde dürfte das Ergebnis nur im Rahmen des Vertragszwecks nutzen (§ 31 Abs. 5 UrhG, der sogenannte Zweckübertragungsgrundsatz). Deshalb ist eine ausdrückliche Rechteübertragungsklausel essentiell. Dies ist auch ein kritischer Punkt für Freelancer, die Rechte an ihrer Arbeit behalten wollen.

Grenzen der Rechteübertragung

Gleichzeitig muss der Vertrag die Grenzen dieser Rechteübertragung adressieren. Die Plattform-Betreiber behalten üblicherweise eigene Rechte an ihren Bausteinen. Lizenzbedingungen der No-Code-Tools können vorsehen, dass Nutzer nur eine beschränkte Lizenz an den vorgefertigten Modulen haben und diese nicht frei weitergeben dürfen.

Der Vertrag sollte also klarstellen, dass der Entwickler nur die Rechte übertragen kann, die bei ihm liegen. Das schließt das Plattform-eigene Material aus. Praktisch heißt das: Der Kunde bekommt die Rechte an der konkreten Kombination und Konfiguration, aber er erhält keine Rechte am Quellcode der Plattform oder an generischen Modulen, soweit diese urheberrechtlich geschützt sind und Dritten gehören.

Im Zweifel muss der Auftraggeber für die Plattform selbst einen Nutzungsvertrag (Lizenzvertrag) abschließen, der ihm die Nutzung der erzeugten Anwendung erlaubt. Ohne Einhaltung der Nutzungsbedingungen der Plattform kann es sonst passieren, dass die Anwendung nicht voll genutzt oder übertragen werden darf. Daher lautet eine Empfehlung: Beide Parteien sollten die AGB/Lizenzbedingungen des gewählten Tools kennen und vertraglich zusichern, diese einzuhalten.

Herausgabe von Unterlagen oder „Quellcode-Äquivalenten“

Besonderes Kopfzerbrechen bereitet vielen die Frage nach der Herausgabe von Unterlagen oder „Quellcode-Äquivalenten“. Da kein Source Code im klassischen Sinne vorhanden ist, sollte man festlegen, was der Entwickler dem Kunden anstelle dessen übergibt. Dies können zum Beispiel folgende Punkte sein:

• Dokumentation und Konfigurationsdateien: Der Entwickler sollte alle relevanten Workflows, Einstellungen und Logiken dokumentieren. Auch ein Export der Projektkonfiguration, soweit technisch möglich (z. B. JSON-Definitionen, Export-Dateien), gehört hierzu.
• Zugangsdaten: Falls die Anwendung auf dem Account des Entwicklers erstellt wurde, muss der Kunde zumindest Administratorzugang erhalten oder – besser – die komplette Übertragung auf einen Kunden-Account erfolgen (z. B. Transfer einer Webflow-Website auf das Konto des Auftraggebers, Eintragung des Kunden als Owner einer Airtable-Base).
• Skripte und externe Codebestandteile: Falls Low-Code doch etwas Code enthält (z. B. selbst geschriebene Skripte, Stylesheets, oder Plugins), sind diese im Quelltext herauszugeben. Hier greift im Grunde der gleiche Maßstab wie bei Individualsoftware: Was individuell programmiert wurde, sollte der Kunde auf Wunsch erhalten.

Ohne solche Vereinbarungen kann es zu unschönen Situationen kommen. Beispiel: Ein Start-up lässt eine komplexe Geschäftslogik in einer No-Code-Datenbank (etwa Airtable mit Automatisierungen) durch einen Dienstleister entwickeln. Im Vertrag wurde nichts über die Herausgabe der Konfiguration oder Dokumentation geregelt. Später will das Start-up einen anderen Entwickler mit Erweiterungen beauftragen und verlangt vom ursprünglichen Dienstleister, alle Einstellungen, Formeldefinitionen und Automatismen offenzulegen.

Rechtlich hätte das Start-up vermutlich keinen Anspruch darauf. Nach der Rechtsprechung (BGH, Urteil vom 16.12.2003 – X ZR 129/01) besteht bei Individualsoftware ein Quellcode-Herausgabeanspruch nur ausnahmsweise, nämlich wenn der Vertragszweck ohne den Code nicht erreicht werden kann oder wenn erkennbar war, dass der Kunde selbst weiterentwickeln will. Hier würde der ursprüngliche Entwickler argumentieren: „Du kannst die Airtable-App doch nutzen wie vereinbart; mehr schulde ich nicht.“ Das Start-up säße dann in der Falle.

Um solche Streitigkeiten zu vermeiden, sollte der Vertrag präzise festlegen, welche Unterlagen, Dateien und Zugänge der Auftraggeber am Ende erhält. Eine mögliche Klausel könnte lauten: „Der Auftragnehmer wird alle zur Nutzung, Wartung und Weiterentwicklung der erstellten Anwendung erforderlichen Unterlagen, Dateien und Zugänge an den Auftraggeber herausgeben. Dies umfasst insbesondere: …“ Diese Liste könnte den Export von Projektdateien, eine ausführliche Dokumentation der Workflows, Admin-Zugangsdaten zur Plattform, API-Dokumentationen etc. enthalten.

Zusätzlich kann man – je nach Projektgröße – sogar an eine Quellcode-Hinterlegung (Escrow) denken: Beispielsweise könnten Konfigurationsdaten oder der Projektstand bei einem unabhängigen Treuhänder hinterlegt werden, der sie dem Kunden aushändigt, falls der Entwickler ausfällt oder insolvent wird.

Aus Entwicklersicht ist verständlich, dass man sensible interne Kenntnisse schützen will. Daher können Schutzmechanismen vorgesehen werden, etwa dass die Herausgabe erst nach vollständiger Bezahlung erfolgt oder dass der Kunde zur Geheimhaltung verpflichtet wird. Wichtig ist jedoch, dass beide Seiten dasselbe Verständnis davon haben, was am Ende geliefert wird – ob es nun Quellcode, Konfigurationsdaten oder zumindest die Zusicherung ist, Zugriff auf alles Wesentliche zu erhalten. Eine klare Vertragsregelung dazu verhindert Enttäuschungen und rechtliche Auseinandersetzungen.

Rechte an Citizen Development

Bei internen Citizen Development-Projekten entsteht oft die Frage, wem die Rechte an einer vom Mitarbeiter erstellten Anwendung zustehen. Hier greift in Deutschland § 69b UrhG: Wird ein Computerprogramm vom Angestellten im Rahmen seiner Aufgaben erstellt, stehen dem Arbeitgeber automatisch alle Vermögensrechte daran zu. Dennoch ist es empfehlenswert, auch in Arbeitsverträgen oder internen Richtlinien klarzustellen, dass Ergebnisse von Citizen Developern dem Unternehmen gehören. Bei externen Freelancern gilt § 69b UrhG nicht – hier muss die Rechteübertragung vertraglich vereinbart werden, sonst verbleiben Urheberrechte beim Entwickler. Es lohnt sich also, kein Detail zu dieser Thematik offenzulassen.

Wartung und Pflege von No-Code-Systemen

Nach der Entwicklung beginnt die Phase der Wartung und Pflege. Gerade bei No-Code-Systemen stellt sich die Frage, wie Wartungsverträge ausgestaltet sein sollten und ob sie sich von herkömmlichen Supportverträgen unterscheiden.

Rechtliche Einordnung von Wartungsverträgen

Zunächst ist die rechtliche Einordnung wichtig: Handelt es sich bei der laufenden Betreuung um einen Dienstvertrag oder einen Werkvertrag? Im deutschen Recht schuldet ein Dienstvertrag (§ 611 BGB) nur ein Tätigwerden ohne garantierten Erfolg, während ein Werkvertrag (§ 631 BGB) einen konkreten Erfolg (ein „Werk“) zum Gegenstand hat, den der Auftraggeber abnimmt.

Wartungsverträge sind in der IT-Praxis häufig Dauerschuldverhältnisse mit regelmäßigen Pflichten (Updates einspielen, Fehler beheben, System überwachen). Die Gerichte tendieren dazu, solche Flatrate-Betreuungen als Dienstverträge zu qualifizieren. Beispiel: Das LG Köln entschied 2015 (Az. 12 O 186/13), dass ein pauschaler Agenturvertrag über laufende Website-Betreuung trotz einiger Werk-Elemente insgesamt ein Dienstvertrag sei – weil die fortlaufende Verfügbarkeit der Leistung im Vordergrund stand, nicht ein einmaliges Arbeitsergebnis. Die Abgrenzung zwischen Dienst- und Werkvertrag ist entscheidend, wie auch unser Beitrag zum Vergütungsanspruch bei schlechter Arbeit im Dienstvertrag beleuchtet.

Inhalt eines Wartungsvertrags für No-Code

Für No-Code-Wartung bedeutet das: Der Vertrag sollte klarstellen, dass Wartungs- und Pflegeleistungen als Dienstvertrag ausgeführt werden, sofern das im Sinne der Parteien ist. Andernfalls könnte ein Kunde später argumentieren, jede kleine Änderung sei ein abnahmefähiges Werk und er habe besondere Rechte (Abnahmeverweigerung, Kündigung nach § 648 BGB etc.).

Durch die ausdrückliche Erklärung „laufende Betreuung als Dienstleistung ohne Erfolgsgarantie“ schafft man Klarheit. Natürlich kann man Entwicklungsleistungen (Werkcharakter) und Wartung (Dienstleistung) auch sauber trennen – etwa durch zwei Verträge oder getrennte Abschnitte im selben Vertrag. Diese Trennung stellt sicher, dass für Entwicklungsprojekte Gewährleistung und Abnahme gelten, während für die anschließende Betreuung andere Regeln (Sorgfaltspflicht, Laufzeit, Kündigungsfristen) greifen.

Inhaltlich sollte ein Wartungsvertrag für No-Code-Plattformen genau beschreiben, welche Leistungen der Dienstleister erbringt. Typische Punkte sind:

• Monitoring der Anwendung
• regelmäßige Updates (soweit vom Plattformanbieter vorgesehen)
• Backup-Erstellung
• Performance-Überwachung
• Bug-Fixing bei auftretenden Störungen

Da viele dieser Tätigkeiten „im Hintergrund“ stattfinden, ist es empfehlenswert, Reporting-Pflichten zu vereinbaren. Beispielsweise kann der Entwickler einen monatlichen Bericht vorlegen über durchgeführte Prüfungen, behobene Fehler, eingespielte Updates etc. Dies schafft Transparenz und Vertrauen – der Auftraggeber sieht, wofür er bezahlt, selbst wenn keine sichtbaren Probleme auftraten. So lassen sich Missverständnisse vermeiden.

Umgang mit zusätzlichen Anforderungen und Plattform-Updates

Eine besondere Herausforderung bei Pauschalwartung ist, wie man mit zusätzlichen Anforderungen umgeht. Oft zahlt der Auftraggeber einen festen Betrag dafür, dass der Dienstleister bereitsteht und kleinere Probleme behebt. Aber was, wenn plötzlich umfangreiche neue Aufgaben anfallen, die ursprünglich nicht abgedeckt waren?

Ein kluger Vertrag wird dafür Mechanismen vorsehen. Zum Beispiel kann geregelt werden, dass größere Änderungen oder Erweiterungen nicht von der Pauschale umfasst sind und nur auf separate Beauftragung (und Vergütung) erfolgen. So vermeidet man Streit darüber, ob eine bestimmte Tätigkeit noch unter „Wartung“ fällt oder schon ein neues Entwicklungsprojekt darstellt.

Gerade bei No-Code-Plattformen sollten Updates des Plattformanbieters bedacht werden: Viele SaaS-Dienste verändern laufend Funktionen. Der Vertrag sollte eine Klausel enthalten, wie mit solchen Änderungen umzugehen ist. Schaltet die Plattform zum Beispiel ein Feature ab oder ändert die Bedienweise, kann das Anpassungen an der Anwendung nötig machen.

Hier muss klar sein, ob der Entwickler solche Anpassungen im Rahmen des Wartungsvertrags schuldet (ggf. bis zu einem gewissen Aufwand gratis) oder ob dies als Change Request zusätzlich in Rechnung gestellt wird. Ohne diese Absprache könnte der Auftraggeber annehmen, alle Änderungen seien abgedeckt, während der Entwickler sie als neuen Auftrag sieht. Ein transparenter Mittelweg könnte sein: Kleinere Anpassungen aufgrund von Plattform-Updates sind inkludiert; größere Umstellungen führen zu einer Vertragsanpassung. Wichtig ist, die Schwelle zu definieren. Für den gesamten Support-Bereich im SaaS-Kontext finden Sie weitere Informationen in unserem Artikel Kundenhotline und Support im SaaS.

Vertragslaufzeit und Kündigungsmodalitäten

Zuletzt verdienen Vertragslaufzeit und Kündigungsmodalitäten Beachtung. Bei Dienstverträgen gilt grundsätzlich „pacta sunt servanda“ – der Vertrag läuft für die vereinbarte Dauer und kann nur ordentlich gekündigt werden (außer es liegt ein wichtiger Grund nach § 626 BGB vor).

Üblich sind feste Mindestlaufzeiten oder Kündigungsfristen, damit der Entwickler Planungssicherheit hat und der Kunde sich binden kann. Hier empfiehlt es sich, klare Fristen in den Wartungsvertrag aufzunehmen (z. B. kündbar erstmals zum Ablauf von 12 Monaten mit 3 Monaten Frist, danach jährlich verlängernd). Ein Sonderfall ist die bereits erwähnte Kündigungsmöglichkeit nach § 648 BGB bei Werkverträgen: Diese sollte bei reinen Wartungsverträgen keine Rolle spielen, solange sie als Dienstvertrag gelten. Umso wichtiger ist es, durch eindeutige Formulierungen einen Mischcharakter zu vermeiden – sonst könnte im Zweifel ein Richter den Vertrag auseinandernehmen und Teile davon als Werkvertrag behandeln.

Zusammenarbeit von Citizen Developern und professionellen Entwicklern

Immer mehr Unternehmen setzen auf einen Mix aus Citizen Development und professioneller Entwicklung. Das heißt, fachliche Anwender ohne klassische Programmierausbildung (Citizen Developer) erstellen einfache Anwendungen oder Prototypen mit Low-Code/No-Code-Tools. Professionelle Entwickler werden für komplexe Aufgaben oder die Gesamtarchitektur hinzugezogen.

Diese Zusammenarbeit kann sehr fruchtbar sein, da sie Fachwissen aus den Abteilungen mit technischem Know-how der IT verbindet. Allerdings sollten einige vertragliche Regelungen getroffen werden, um die Kooperation reibungslos zu gestalten.

Rollen und Verantwortlichkeiten definieren

Zunächst ist wichtig, Rollen und Verantwortlichkeiten klar zu definieren. Im Vertrag (oder Projektplan) sollte festgehalten werden, welche Aufgaben der externe Entwickler beziehungsweise die Agentur übernimmt und was vom internen Citizen Developer oder dem Team des Auftraggebers erledigt wird.

Beispiel: „Der Auftraggeber stellt einen fachlichen Mitarbeiter, der die Grundkonfiguration in der Plattform XY vornimmt. Der Auftragnehmer entwickelt daran anschließende individuelle Module und übernimmt die Integration in bestehende Systeme.“ Eine solche Beschreibung verhindert Überschneidungen und Lücken, sodass beide Seiten wissen, wer wofür zuständig ist.

Haftungsfragen bei Eigenbeteiligung

Haftungsfragen ergeben sich insbesondere dort, wo sich die Arbeitsbereiche berühren. Wenn der Auftraggeber selbst an der Anwendung mitbaut, sollte vertraglich geregelt sein, dass der professionelle Entwickler nicht für Fehler haftet, die durch Eingriffe des Auftraggebers entstehen.

Umgekehrt sollte der Auftraggeber sicherstellen, dass seine Mitarbeiter die nötigen Kenntnisse und Befugnisse haben, um mit der Plattform zu arbeiten – der externe Entwickler kann nicht die volle Verantwortung für Laienfehler tragen. Ein Ansatz kann sein, dass der Citizen Developer bestimmte sensiblere Bereiche (z. B. sicherheitsrelevante Einstellungen oder Integrationen mit Drittsystemen) nicht ohne Rücksprache ändert, oder dass der externe Dienstleister vor dem Go-Live alle Änderungen überprüft. Solche Abstimmungsprozesse können informell gehandhabt werden, doch ein kurzer Hinweis im Vertrag schadet nicht, damit die Erwartungen klar sind.

Zusammenführung der Arbeitsergebnisse

Auch die Zusammenführung der Arbeitsergebnisse ist ein Thema. Wenn mehrere Personen an einer Low-Code-Plattform arbeiten, besteht die Gefahr von Konflikten – sowohl im technischen als auch im organisatorischen Sinne. Es kann sinnvoll sein, Zugriffsrechte und Umgebungen festzulegen: Zum Beispiel arbeitet der Citizen Developer in einem Test-Workspace und der Profi-Entwickler übernimmt das Deployment in den Produktiv-Workspace.

Vertraglich muss das nicht bis ins Detail beschrieben sein, aber zumindest die Pflicht zur Kooperation und Abstimmung sollte genannt werden. Beide Parteien sollten verpflichtet sein, konstruktiv zusammenzuarbeiten, sich Änderungen mitzuteilen und gemeinsame Standards einzuhalten, damit das Endprodukt konsistent ist. Dies lässt sich allgemeiner als Kooperationsklausel formulieren.

Geheimhaltung und Datenschutz

Ein weiterer Aspekt ist die Geheimhaltung und der Datenschutz. Wenn externe Entwickler und interne Mitarbeiter zusammenwirken, werden zwangsläufig Informationen ausgetauscht. Eine NDA (Geheimhaltungsvereinbarung) ist heutzutage Standard, aber im Vertrag kann nochmals betont werden, dass beide Seiten vertrauliche Informationen der jeweils anderen Seite schützen.

Das gilt insbesondere, wenn Citizen Developer Einblick in den Code oder die Methoden des externen Entwicklers erhalten (und umgekehrt). Zudem sollte abgestimmt sein, wer administrativen Zugriff auf welche Systeme hat und wie sensiblen Daten umgegangen wird, um Compliance-Probleme zu vermeiden. Aktuelle Neuerungen im Datenschutzrecht sollten dabei stets beachtet werden.

Rechteübertragung bei Kooperation

Nicht zuletzt spielt die Rechteübertragung hier wieder eine Rolle: Arbeiten interne und externe Entwickler gemeinsam an einem Produkt, muss sichergestellt sein, dass am Ende alle Teile vom Auftraggeber genutzt werden dürfen. Der externe Entwickler wird wie üblich seine Rechte am Beitrag übertragen (siehe oben), während beim internen Citizen Developer § 69b UrhG greift (Arbeitgeberrechte an Software).

Trotzdem kann der Vertrag einen Passus enthalten, der klarstellt, dass sämtliche Resultate des Projekts dem Auftraggeber zur Nutzung zustehen, unabhängig davon, wer sie erstellt hat. Das schafft Klarheit auch gegenüber eventuell beteiligten Freelancern oder Subunternehmern.

Fazit in diesem Punkt: Citizen Developer und Profis können durchaus sinnvoll Hand in Hand arbeiten – das Unternehmen profitiert von schneller Entwicklung und gleichzeitig von Qualitätssicherung. Damit das gelingt, sollte der Vertrag die Spielregeln der Zusammenarbeit definieren: Keine ungeregelten Eingriffe, Transparenz über Änderungen, geregelte Verantwortlichkeiten und ein Mechanismus zur Abstimmung. Beispielsweise könnte man regelmäßige Meetings vereinbaren oder einen technischen Lead bestimmen. Zudem können Schulungen vereinbart werden: Der professionelle Entwickler kann den Citizen Developer trainieren, was wiederum im Vertrag als Leistung (Know-how-Transfer) aufgeführt werden kann. Agile Entwicklungsverträge können hierfür eine gute Grundlage bieten.

Fazit

No-Code und Low-Code eröffnen neue Chancen in der Softwareentwicklung. Doch die vertraglichen Regelungen müssen Schritt halten. Ein Vertrag für ein No-Code-/Low-Code-Projekt sollte daher speziell auf die Besonderheiten dieser Methode zugeschnitten sein.

Empfehlenswert sind klare Klauseln zu Leistungsumfang, Nutzungsrechten (inklusive Quellcode-Äquivalenten), Haftung bei Plattformausfällen und Wartungsmodalitäten. Auch die Aufklärungspflicht des Entwicklers über Risiken und Grenzen ist hervorzuheben, um spätere Konflikte zu vermeiden. Wartungsverträge im No-Code-Umfeld sind meist als Dienstverträge zu gestalten und bedürfen transparenter Absprachen über den Umfang der Betreuung. Schließlich kann die Kombination aus Citizen Developer und Professional ein Erfolgsrezept sein – sofern vertraglich festgelegt ist, wer welche Rolle einnimmt und wie Zusammenarbeit und Verantwortung verteilt sind.

Insgesamt gilt: Standardmuster reichen oft nicht aus, um Verträge für No-Code oder Low-Code Entwicklung abzudecken. Beide Parteien sollten sorgfältig prüfen, ob alle wichtigen Punkte abgedeckt sind – von „Vertrag No-Code“-Spezifika über „Haftung Low-Code“-Risiken bis hin zu „Wartung No-Code-Plattform“-Regelungen. Eine fundierte, individuelle Vertragsgestaltung schafft Sicherheit und Vertrauen und stellt sicher, dass innovative Technologien rechtlich sauber eingesetzt werden können.