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: Unklare Leistungspflichten, Streit um fehlenden Quellcode, Abhängigkeiten von Drittplattformen oder Lücken bei den Nutzungsrechten könnten zu Konflikten führen. Im Folgenden werden die wichtigsten Punkte beleuchtet, damit Verträge für No-Code-/Low-Code-Softwareentwicklung professionell und rechtssicher gestaltet werden – neutral und fundiert aus juristischer Sicht.
Besondere Vertragsklauseln bei No-Code-/Low-Code-Entwicklung
Wenn Software ganz oder teilweise mit No-Code-/Low-Code-Tools erstellt wird, sollten Verträge einige besondere Klauseln enthalten, die über Standard-Softwareverträge hinausgehen. Wichtig ist zunächst eine klare Definition des Leistungsumfangs: Was genau schuldet der Entwickler? 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 – z. B. die funktionsfähige Anwendung auf der gewählten Plattform inklusive aller Workflows, Einstellungen und erforderlichen Zugänge.
Zudem sollten Nutzungsrechte und Eigentumsrechte ausdrücklich geregelt werden. Der Auftraggeber muss das Recht erhalten, die entwickelte No-Code-Anwendung wie vorgesehen zu nutzen (ggf. exklusiv, falls gewünscht). 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. Beispielsweise darf der Kunde eine auf Webflow erstellte Website nutzen und inhaltlich verändern, er erwirbt aber natürlich keine Rechte an der Webflow-Software oder allgemeinen Design-Templates der Plattform. Solche Klauseln klingen selbstverständlich, sind aber im Streitfall Gold wert. Überschriften wie “Nutzungsrechte Softwareentwicklung” oder “Rechte an No-Code-Bestandteilen” helfen, die Bedeutung hervorzuheben.
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 z. B. eigene Lizenzen oder Abonnements für Airtable, Webflow & Co. bereitstellen? Trägt er die Gebühren direkt, oder beschafft der Entwickler die nötigen 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). Außerdem ist festzuhalten, dass der Entwickler nicht für die Leistung dieser externen 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.
Praxis-Tipp: Häufig ist es sinnvoll, dass der Auftraggeber frühzeitig eigene Accounts bei den benötigten No-Code-Plattformen einrichtet (oder dem Entwickler Zugang zu seinem Konto gewährt). So bleibt die Kontrolle beim Kunden, und die fertige Anwendung kann am Vertragsende leicht auf den Kunden ü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 Anforderungen des Kunden 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 kann man geringere Erläuterungen voraussetzen.
Konkret bedeutet das: Der Entwickler muss den Auftraggeber vor Vertragsschluss und während der Umsetzung auf wesentliche Grenzen der No-Code-Tools hinweisen. Wenn beispielsweise eine bestimmte gewünschte Funktionalität mit der gewählten Plattform nicht umsetzbar ist oder nur mit Workarounds, muss der Kunde das frühzeitig erfahren. Ebenso sind Risiken wie Skalierungsgrenzen (z. B. maximale Nutzerzahlen oder Datenmengen, die das System verkraftet) offen zu legen. Auch die Gefahr einer vendor lock-in – also 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 Wechsel der Plattform später mit erheblichem Aufwand verbunden sein kann.
Beispiel aus der Praxis: 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 dass 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 – z. B. 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. Daher: Transparenz von Anfang an schützt beide Seiten.
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.
Grundsätzlich gilt: Der Entwickler schuldet die vertraglich vereinbarte Leistung, also z. B. 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, die den Entwickler von der Haftung für Umstände freistellt, die außerhalb seiner Kontrolle liegen (vgl. § 276 Abs. 1 BGB zur Verantwortlichkeit). Ein Beispiel wäre eine Klausel, die Ausfälle oder Leistungsminderungen der zugrundeliegenden SaaS-Plattform als höhere Gewalt oder als vom Entwickler nicht zu vertretende Umstände definiert. Dadurch kann klargestellt werden, dass solche externen 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. Hat man nichts geregelt, 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 (weil er z. B. nicht durch dessen eigenes Tun verursacht wurde), haftet er hierfür nicht. Stattdessen wäre es ein Fall für den Support des Plattformanbieters oder (falls vereinbart) ein gemeinsames Krisenmanagement, bei dem der Entwickler gegen zusätzliche Vergütung bei der Fehlersuche unterstützt.
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 oder dass der Auftraggeber ein Sonderkündigungsrecht hat, 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.).
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 oder nach Produkthaftungsgesetz – solche bestehen im reinen Softwarebereich aber selten. Wichtig: 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 – oft verbunden mit der Herausgabe des Quellcodes an den Auftraggeber. 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.
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 sog. Zweckübertragungsgrundsatz). Deshalb ist eine ausdrückliche Rechteübertragungsklausel essentiell.
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.
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 z. B. 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 Scripts, 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: [Liste konkreter Punkte].” 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.
Hinweis: Bei internen Citizen Development-Projekten (dazu später mehr) 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. 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.
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, und 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 (Stichwort: “Hier wird gar nichts getan!”).
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 z. B. 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.
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, während professionelle Entwickler für komplexe Aufgaben oder die Gesamtarchitektur hinzugezogen werden. Diese Zusammenarbeit kann sehr fruchtbar sein – sie verbindet Fachwissen aus den Abteilungen mit technischem Know-how der IT. Allerdings sollten einige vertragliche Regelungen getroffen werden, um die Kooperation reibungslos zu gestalten.
Zunächst ist wichtig, Rollen und Verantwortlichkeiten klar zu definieren. Im Vertrag (oder Projektplan) sollte festgehalten werden, welche Aufgaben der externe Entwickler bzw. die Agentur übernimmt und was vom internen Citizen Developer oder dem Team des Auftraggebers erledigt wird. Zum 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. Beide Seiten wissen, wer wofür zuständig ist.
Haftungsfragen ergeben sich insbesondere dort, wo die Arbeitsbereiche sich 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.
Auch die Zusammenführung der Arbeitsergebnisse ist ein Thema. Wenn mehrere Personen an einer Low-Code-Plattform arbeiten, besteht die Gefahr von Konflikten (im technischen Sinne wie auch im organisatorischen). Es kann sinnvoll sein, Zugriffsrechte und Umgebungen festzulegen: Zum Beispiel arbeitet der Citizen Developer in einer Test-Workspace und der Profi-Entwickler übernimmt das Deployment ins 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.
Ein weiterer Aspekt ist die Geheimhaltung und 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.
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 (etwa den Profi-Entwickler als finalen Qualitätsprüfer). So werden Missverständnisse vermieden. 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.
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 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. Sie stellt sicher, dass innovative Technologien rechtlich sauber eingesetzt werden können und sowohl Auftraggeber als auch Entwickler im Ernstfall geschützt sind. Damit steht einer erfolgreichen Zusammenarbeit nichts im Wege – und die Vorteile der No-Code/Low-Code-Ansätze können voll ausgeschöpft werden.
