So prüfen und gestalten wir Ihren App-Entwicklungsvertrag
App-Projekt in Schieflage oder Vertrag vor der Unterschrift? Wir prüfen Abnahme, Quellcode, Store-Accounts und Signing-Zertifikate für iOS und Android.
Ein App-Entwicklungsvertrag sieht im Startup- und Mittelstandsalltag oft wie eine Formalie aus: ein paar Seiten von der Agentur, ein Lastenheft aus dem Produkt-Team, ein Festpreis-Angebot, eine Unterschrift. Sobald das Projekt jedoch in die neunte oder zwölfte Woche läuft, der Store-Release blockiert wird oder die Agentur den Zugriff auf Quellcode und Signing-Zertifikate zurückhält, zeigt sich, wie teuer diese “paar Seiten” wirklich sind. Für die übergreifende Vertrags- und Plattformperspektive bietet unsere fachkundige Vertretung im IT-Recht den passenden Rahmen.
Mobile Apps haben eine eigene juristische Logik. Sie sind urheberrechtlich geschützte Computerprogramme nach §§ 69a ff. UrhG, werden werkvertraglich hergestellt, in fremdverwalteten App-Stores distribuiert und sind von Anfang an datenschutzrechtlich und storepolitisch hart reguliert. Hinzu kommen branchenspezifische Anforderungen - von BaFin-Vorgaben bei Fintech-Apps bis zum Barrierefreiheitsstärkungsgesetz ab Mitte 2025. Ein App-Vertrag, der diese Ebenen nicht sauber abbildet, produziert bei jedem Release einen neuen Verhandlungsfall.
Dieser Leitfaden beantwortet drei Fragen:
- Welchem Vertragstyp unterliegt ein App-Entwicklungsprojekt und welche Rechte haben Auftraggeber bei Abnahme, Mängeln und Verzug?
- Welche Klauseln sind die stillen Sollbruchstellen - rund um Quellcode, Store-Accounts, Signing-Zertifikate, Open-Source und DSGVO?
- Welche Hebel bleiben, wenn die App-Agentur nicht mehr liefert, insolvent wird oder die Herausgabe von Assets verweigert?
Für laufende SaaS-Angebote, reine IT-Pflege oder KI-gestützte Systeme gelten teilweise andere Regeln - dazu der Hinweis auf die jeweils passende Schwesterseite am Ende der Lösungssektion.
Welchem Vertragstyp ein App-Entwicklungsprojekt unterliegt
Der häufigste Fehler in App-Projekten ist, dass Auftraggeber und Agentur von unterschiedlichen Vertragstypen ausgehen. Der Auftraggeber erwartet ein konkretes Ergebnis, die Agentur möchte Stunden oder Sprints abrechnen - und beide Seiten berufen sich bei Streit auf unterschiedliche Regelwerke.
Nach der Rechtsprechung des Bundesgerichtshofs ist ein Vertrag über die Erstellung individueller Software mit konkret spezifizierter Funktionalität regelmäßig als Werkvertrag im Sinne der §§ 631 ff. BGB einzuordnen.
Der Bundesgerichtshof hat in ständiger Rechtsprechung klargestellt, dass Verträge über die Erstellung oder Bearbeitung einer speziell auf die Bedürfnisse des Auftraggebers abgestimmten Software regelmäßig als Werkvertrag im Sinne der §§ 631 ff. BGB anzusehen sind, wobei der geschuldete Erfolg in der Herbeiführung des vertraglich vereinbarten Erfolgs als Ergebnis einer individuellen Tätigkeit besteht.
Besondere Vorsicht gilt bei hybriden Projekten: Wenn Ihre Agentur zusätzlich zur App ein eigenes Backend baut und dieses später als Cloud-Dienst betreiben soll, liegen oft mehrere Vertragstypen nebeneinander.
Werkvertrag, Sprint-Contract oder Rahmenvereinbarung vor der Unterschrift - wir ordnen die Rechtsnatur und zeigen Risiken auf.
Kostenlose Anfrage- Kostenlos beraten
- Kein Risiko, 100% vertraulich
Wo App-Projekte in der Praxis eskalieren
App-Entwicklungsprojekte scheitern selten an einem einzelnen technischen Defekt. Sie scheitern an strukturellen Leerstellen im Vertrag, die sich meist erst im Spätstadium zeigen - oft kurz vor dem geplanten Go-Live oder beim ersten Versuch, die Agentur zu wechseln.
Abnahme-Streit und die Falle der fiktiven Abnahme
Die Abnahme ist der juristische Dreh- und Angelpunkt jedes Werkvertrags. Mit ihr wird die Restvergütung fällig, es beginnt die Verjährung der Mängelrechte nach § 634a BGB, und die Beweislast für Mängel verschiebt sich zu Ungunsten des Auftraggebers. Wer die Abnahme zu spät oder zu zögerlich behandelt, verschenkt die stärkste Verhandlungsposition im Projekt.
Nach § 640 BGB ist die Abnahme das zentrale Ereignis eines Werkvertrags: Mit ihr wird die Vergütung fällig, die Verjährung der Mängelrechte beginnt und die Beweislast für Mängel verschiebt sich regelmäßig auf den Auftraggeber.
Nach § 640 Absatz 2 BGB gilt ein Werk als abgenommen, wenn der Unternehmer dem Besteller nach Fertigstellung eine angemessene Frist zur Abnahme gesetzt hat und der Besteller die Abnahme nicht innerhalb dieser Frist unter Angabe mindestens eines Mangels verweigert.
Nach der Rechtsprechung setzt die Abnahmefähigkeit einer Softwareleistung die praktische Einsatzfähigkeit im vertraglich vorausgesetzten Umfang voraus; eine rein theoretische Funktionsfähigkeit genügt nicht.
Konkret bedeutet das für App-Projekte: Ein Slack-Link zu einem TestFlight-Build ist keine Abnahmeerklärung, aber eine fehlende schriftliche Verweigerung kann zur fiktiven Abnahme führen. Der Vertrag sollte deshalb eine eigene Abnahmelogik enthalten - mit realistischer Prüffrist von mindestens drei bis vier Wochen, definierten Test-Devices und Betriebssystem-Versionen, messbaren Acceptance-Kriterien und einer klaren Eskalationsregel bei wesentlichen Mängeln.
In der Praxis sind das vor allem: Crash-Raten oberhalb definierter Schwellen, fehlende Kernfeatures aus dem Lastenheft, Ablehnung der App durch Apple oder Google wegen geschuldeter Store-Konformität, fehlende Datenschutz-Privacy-Labels oder nicht erfüllte Performance-Baselines. Wer diese Kriterien nicht in den Vertrag aufnimmt, verhandelt später gegen eine Agentur, die im Zweifel auf vage Branchenmaßstäbe verweisen kann.
Ownership-Deadlock bei Quellcode, Accounts und Signing-Zertifikaten
Der zweite große Konfliktbereich entsteht nicht im Projekt selbst, sondern danach - in dem Moment, in dem der Auftraggeber den Entwickler wechseln, ein Sicherheits-Update einspielen oder die App an einen neuen Dienstleister übergeben möchte. Wenn Quellcode, Zertifikate und Accounts bei der Agentur verbleiben, steht der Auftraggeber faktisch still.
Urheberrechtlich ist die App ein Computerprogramm mit einem eigenen Sonderregime. Ohne ausdrückliche vertragliche Regelung erhält der Auftraggeber nur das Nutzungsrecht am fertigen Programm - nicht aber das Bearbeitungsrecht am Quellcode.
Computerprogramme einschließlich Entwurfsmaterial sind nach § 69a UrhG als Sprachwerke urheberrechtlich geschützt; zustimmungsbedürftige Handlungen wie die Bearbeitung und die öffentliche Zugänglichmachung sind in § 69c UrhG gesondert geregelt.
Nach dem Zweckübertragungsgrundsatz des § 31 Absatz 5 UrhG verbleiben im Zweifel beim Urheber alle Nutzungsrechte, die nicht ausdrücklich und zweckbezogen eingeräumt worden sind.
Ein Anspruch auf Herausgabe des Quellcodes einer individuell entwickelten App folgt nicht automatisch aus dem Werkvertrag, sondern setzt eine ausdrückliche vertragliche Vereinbarung über Umfang, Form und Zeitpunkt der Übergabe voraus.
Konkret bedeutet das für Auftraggeber: Ohne passende Klausel haben Sie im Zweifel nur ein einfaches Nutzungsrecht an den fertig kompilierten Binaries - nicht am Quellcode, nicht an den Build-Skripten, nicht an der CI/CD-Pipeline. Eine Weiterentwicklung durch einen anderen Entwickler ist dann rechtlich und faktisch blockiert.
Hinzu kommt das App-spezifische Problem der Plattform-Accounts und Signing-Identitäten. Der Apple Developer Account, die Google Play Console, die Bundle-IDs, APNs-Zertifikate für Push-Notifications, Keystore-Passwörter für Android und die Signing-Identities für iOS sind keine urheberrechtlichen Assets - sie sind Plattform-Konten, die einem bestimmten Inhaber zugewiesen sind. Wenn die Agentur hier als Account-Owner eingetragen ist, gehören sie im Zweifel der Agentur. Kein Gericht kann Ihnen den Apple Developer Account der Agentur “übertragen”; Sie müssten einen neuen Account registrieren, eine neue Bundle-ID vergeben, die App formal neu veröffentlichen - und damit alle bisherigen Reviews, Downloads und Nutzer-Daten verlieren.
Wir regeln deshalb in App-Verträgen konsequent vor Projektstart: Alle Plattform-Accounts werden auf Konten des Auftraggebers registriert, die Agentur erhält lediglich Collaborator-Rollen mit Ablaufdatum, Signing-Keys werden auf einer Infrastruktur des Auftraggebers verwahrt und monatlich gesichert. Diese Vorarbeit erspart im Konfliktfall sechsstellige Wiederherstellungskosten.
Scope-Creep, Change Requests und Meilenstein-Traps
Viele App-Projekte starten mit einem Festpreis, den beide Seiten für realistisch halten, und enden nach zwölf Monaten bei dem Doppelten. Dazwischen liegt eine Kette von “kleinen Änderungen”, “notwendigen Klarstellungen” und “technischen Anpassungen”, die ohne formalen Change-Request-Prozess in Stundenabrechnungen oder Change-Request-Rechnungen münden.
Genau das ist der Grund, warum bei Werkverträgen Meilensteine mit quantifizierten Acceptance-Kriterien so wichtig sind. Der Milestone “Backend-APIs functional” ist keine Abnahmebasis - der Milestone “GET /users returns 200 mit definierter JSON-Struktur, POST /login verlangt gültigen JWT, 95-Percentile-Response unter 500 Millisekunden, OpenAPI-Spec gepflegt” ist es. Ohne diese Ebene wird die Milestone-Zahlung zu einem reinen Vertrauensgeschäft, und Abnahmeverweigerungen scheitern daran, dass die Agentur schlicht ihre eigene Auslegung des Milestones als Maßstab anlegt.
Für Change Requests empfehlen wir eine gestaffelte Matrix: Kleinänderungen unterhalb einer festen Stundenschwelle gelten als Agentur-Kosten im Rahmen des Festpreises, mittelgroße Änderungen erfordern eine schriftliche Estimate mit expliziter Preisfreigabe durch den Auftraggeber, Scope-Erweiterungen oberhalb einer zweiten Schwelle werden als formale Vertragsänderung behandelt. Ohne diese Staffelung wird jeder Slack-Kommentar zum möglichen Streitpunkt.
Agentur-Ausfall, Insolvenz und das Ende der Kommunikation
Der härteste Konfliktfall ist derjenige, in dem die Gegenseite nicht mehr existiert - weil die Agentur Insolvenz anmeldet, weil der Freelancer in eine Auszeit geht oder weil das Entwickler-Team das Unternehmen verlässt. Ohne vertragliche Vorsorge droht nicht nur der Verlust laufender Arbeit, sondern auch der Zugriff auf bereits bezahlte Leistungen.
Nach § 103 InsO kann der Insolvenzverwalter wählen, ob er einen bei Eröffnung des Insolvenzverfahrens beiderseits noch nicht vollständig erfüllten gegenseitigen Vertrag erfüllt oder die Erfüllung ablehnt.
Lehnt der Insolvenzverwalter den App-Entwicklungsvertrag ab, fallen Quellcode, angefangene Builds, Assets und Rechteeinräumungen in die Insolvenzmasse. Der Auftraggeber hat zwar einen Anspruch auf Rückerstattung der geleisteten Anzahlungen, muss ihn aber als einfache Insolvenzforderung zur Tabelle anmelden - und erhält in der Praxis häufig nur einen geringen Teil zurück.
Die wirtschaftlich sinnvolle Antwort darauf ist ein Source-Code-Escrow. Der Quellcode wird regelmäßig bei einem neutralen Treuhänder hinterlegt und unter klar definierten Bedingungen an den Auftraggeber freigegeben - etwa bei Insolvenzantrag, bei dauerhafter Nichterbringung oder bei Ausbleiben der Kommunikation über eine definierte Frist hinweg.
Nach der Rechtsprechung des Bundesgerichtshofs können Escrow- und Hinterlegungsvereinbarungen zugunsten Dritter im Insolvenzfall eine echte Sicherungsfunktion entfalten, wenn die Herausgabevoraussetzungen eindeutig definiert und die Verwahrung eigenständig vom Vermögen des Schuldners getrennt ist.
Konkret bedeutet das für Auftraggeber: Eine Escrow-Klausel ohne sauber definierten Insolvenz-Trigger und ohne echten Drei-Parteien-Vertrag mit dem Treuhänder ist wirkungslos - sie wirkt auf dem Papier, liefert im Ernstfall aber keinen Zugriff. Wir gestalten Hauptvertrag, Escrow-Agreement und Insolvenzszenarien so aufeinander ab, dass die Sicherungslinie im Ernstfall auch wirklich trägt.
Abnahme verweigert, Quellcode bei der Agentur oder Agentur-Insolvenz - wir ordnen die Hebel und sichern Ihre Position.
Kostenlose Anfrage- Kostenlos beraten
- Kein Risiko, 100% vertraulich
Store-Compliance, Accounts und Signing - der versteckte USP jedes App-Projekts
Der größte Unterschied zwischen klassischer Software- und App-Entwicklung liegt in der Plattform-Abhängigkeit. Eine App lebt nicht in Ihrem Rechenzentrum, sondern im Apple App Store oder auf Google Play. Wer dort nicht veröffentlicht werden darf, hat wirtschaftlich keine App - und zwar unabhängig davon, wie gut der Quellcode ist. Diese Ebene wird in Standard-Werkverträgen regelmäßig unterschätzt.
Apple App Store Review Guidelines und Google Play Policies als Leistungsstandard
Die Apple App Store Review Guidelines und die Google Play Developer Program Policies sind privatrechtliche AGB der jeweiligen Plattform-Betreiber. Sie regeln, welche Apps unter welchen Bedingungen veröffentlicht werden dürfen, welche Datenschutz-Labels zu setzen sind, wie In-App-Käufe zu implementieren sind und wie Apps mit externen Zahlungsflüssen umgehen dürfen. Für den Vertrag zwischen Auftraggeber und Agentur sind diese Policies faktische Leistungsstandards: Eine App, die nicht in den Store gelangt, ist wirtschaftlich wertlos.
Die Ablehnung einer App durch Apple oder Google wegen Verstößen gegen die Store-Policies stellt einen Sachmangel im Sinne von § 633 BGB dar, wenn die Store-Policy-Konformität ausdrücklich oder konkludent geschuldet war und der Verstoß im Verantwortungsbereich des Entwicklers liegt.
Der Vertrag sollte deshalb klarstellen, welche Store-Policy-Version als Referenz gilt, wer das Risiko kurzfristiger Policy-Änderungen durch die Plattform-Betreiber trägt - hier empfehlen wir einen Change-Request-Prozess statt einer Mangelrüge - und wie Re-Submissions bei Store-Rejections abzuwickeln sind. Empfehlenswert ist eine klare Aufteilung: Technische Rejections (fehlerhafte Privacy-Label-Konfiguration, StoreKit-Fehlimplementierung, Architektur-Issues) sind Agentur-Sache; fehlende Unterlagen (Datenschutzerklärung, Terms of Service, Marketing-Screenshots) liegen beim Auftraggeber. Wer diese Trennung nicht vorab regelt, streitet bei jeder Rejection neu.
Typische Kostenfalle bei Store-Rejections
In der Praxis führt die erste App-Store-Rejection regelmäßig zu einem mehrtägigen Eskalations-Ping-Pong: Die Agentur verweist auf “Publisher- Verantwortung”, der Auftraggeber auf die geschuldete Store-Konformität, und die App liegt in der Zwischenzeit blockiert. Eine saubere Vertragsklausel mit Zuordnungsmatrix, Reaktionsfrist und definierter Remediation- Verantwortung verhindert genau diese tagelangen Verlustschleifen.
Plattform-Accounts, Bundle-IDs und Signing-Identitäten
Getrennt von der Content-Ebene existiert die Account-Ebene.
Für den Vertrag heißt das: Diese Assets müssen von Anfang an auf den Auftraggeber registriert sein. Wir regeln konkret:
- Apple Developer Account auf Auftraggeber-Apple-ID mit unternehmensintern verwalteter Zwei-Faktor-Authentifizierung – Die Agentur erhält Admin-Rolle oder Developer-Rolle, nicht Account-Owner-Status
- Google Play Developer Console auf Auftraggeber-Google-Account als Inhaber – Agentur-Rollen mit definiertem Ablaufdatum und widerrufbarem Zugriff
- Code-Signing-Identitäten auf Auftraggeber-Infrastruktur erzeugen und sichern – Keystores, iOS-Zertifikate und Provisioning-Profiles liegen zentral beim Auftraggeber; Agentur nutzt sie projektbezogen
- APNs-Zertifikate für Push-Notifications ebenfalls auftraggeberseitig – Damit bleibt die Kommunikation mit Bestandsnutzern auch nach Agentur-Wechsel möglich
- Backend-API-Keys und Third-Party-SDK-Credentials in Auftraggeber-Secret-Management – Keine hardcoded Keys in Agentur-Config; alle Credentials rotierbar und dokumentiert
Diese Ownership-Klauseln sind die wirtschaftlich wertvollste Absicherung jedes App-Entwicklungsvertrags. Ohne sie werden Agentur-Wechsel, Wartungsübergaben und Konfliktsituationen im Extremfall zum wirtschaftlichen Totalverlust der App.
Open-Source-Compliance und Copyleft-Risiken
Apps bestehen technisch zu großen Teilen aus Drittbibliotheken - nativen SDKs, Cross-Platform-Frameworks, Analytics- und Werbe-Modulen, Payment-Komponenten. Jede dieser Bibliotheken hat eine eigene Lizenz, und manche dieser Lizenzen sind mit der proprietären Distribution einer App im App Store oder auf Google Play nicht oder nur eingeschränkt vereinbar.
Die Verwendung von Komponenten unter GPL oder AGPL in einer proprietär distributierten App kann nach deutscher Rechtsprechung zu einer urheberrechtlich relevanten Copyleft-Pflicht führen, deren Verletzung Unterlassungs- und Schadensersatzansprüche nach § 97 UrhG auslöst, wie das LG München I mit Urteil vom 19. Mai 2004 (Az. 21 O 6123/04) bestätigt hat.
Das Landgericht München I hat im sogenannten Welte-Verfahren mit Urteil vom 19. Mai 2004 (Az. 21 O 6123/04) und nachfolgenden Entscheidungen bestätigt, dass die GNU General Public License in Deutschland wirksam und durchsetzbar ist und eine Verletzung ihrer Bedingungen zugleich eine Urheberrechtsverletzung nach § 69c UrhG darstellt.
Konkret bedeutet das für App-Projekte: GPL- und AGPL-lizenzierte Bibliotheken sind in einer kommerziell vertriebenen App ohne sehr sorgfältige technische und rechtliche Trennung in der Regel nicht nutzbar. LGPL ist im iOS-Kontext heikel, weil Apples Regeln zu Dynamic Frameworks das klassische LGPL-Linking-Modell erschweren. MIT, Apache 2.0 und BSD sind demgegenüber unkritisch - erfordern aber eine saubere Attribution in der App.
Wir regeln im Vertrag deshalb eine strukturierte Open-Source-Compliance: Eine Approved/Banned-Library-Liste, verbindliche Software-Bill-of-Materials vor jedem Major-Release, eine Prüfpflicht der Agentur bei jeder Dependency-Änderung und eine klare Haftung, wenn Copyleft-Komponenten nachträglich das Distributionsmodell sprengen. Gerade Cross-Platform-Frameworks wie React Native oder Flutter bringen ein großes Abhängigkeits-Ökosystem mit, dessen Transitive-Dependencies regelmäßig kontrolliert werden müssen.
Datenschutz, AVV und Tracking-SDKs als Vertragsthema
Kaum eine App kommt ohne personenbezogene Daten aus. Selbst eine reine Funktions-App speichert Geräte-Identifikatoren, Log-Daten oder Crash-Reports - und die meisten Apps integrieren darüber hinaus Analytics-, Marketing- oder Push-Dienste, deren Datenflüsse durch SDK-Anbieter laufen. Das macht jede App zu einem DSGVO-Projekt.
Die Verarbeitung personenbezogener Daten durch eine Agentur im Auftrag des App-Betreibers löst grundsätzlich die Pflicht zum Abschluss eines schriftlichen Auftragsverarbeitungsvertrags mit den Mindestinhalten des Artikel 28 Absatz 3 DSGVO aus.
Das Setzen und Auslesen von Cookies, Geräte-Identifikatoren oder vergleichbaren Informationen auf dem Endgerät der Nutzer erfordert nach § 25 TDDDG eine informierte Einwilligung, soweit der Zugriff nicht für die ausdrücklich vom Nutzer gewünschte Funktion der App unbedingt erforderlich ist.
Die Integration von Analyse-, Werbe- oder Tracking-SDKs in eine App führt bei Übermittlungen personenbezogener Daten in Drittländer regelmäßig zu zusätzlichen Pflichten nach Kapitel V der DSGVO, einschließlich der Nutzung geeigneter Garantien und einer dokumentierten Transfer Impact Assessment.
Konkret bedeutet das für Auftraggeber: Ein App-Entwicklungsvertrag sollte die Rollenverteilung zwischen Auftraggeber (Verantwortlicher nach Art. 4 DSGVO), Agentur (Auftragsverarbeiter oder Joint Controller) und Third-Party-SDK-Anbietern klar regeln. Die AVV nach Art. 28 DSGVO gehört als verbindliche Anlage in den Vertrag. Jede Analytics-, Crash-Reporting-, Attribution- oder Push-Integration benötigt eine eigene Prüfung: Rechtsgrundlage, Einwilligungsflow, Drittlandtransfer, Transfer Impact Assessment. Ohne diese Vorarbeit ist die App bei der ersten datenschutzbehördlichen Prüfung angreifbar - und die Verantwortung trägt im Außenverhältnis regelmäßig der Auftraggeber als Verantwortlicher, nicht die Agentur.
Ergänzt wird das durch eine saubere Consent-Architektur innerhalb der App: Consent-Banner vor dem ersten Tracking-Call, granulare Kategorien (notwendig, funktional, Analyse, Marketing), persistente Speicherung der Entscheidung, gleich einfacher Widerruf wie Erteilung. Die Technische Umsetzung gehört in den Leistungsumfang der Agentur; die Vorgaben für Text und Kategorien sind Sache des Auftraggebers - diese Trennung muss im Vertrag stehen.
Neue regulatorische Pflichten - BFSG, AI Act, Data Act
Ab Mitte 2025 verschärft sich die Regulierungsebene für Apps deutlich. Auftraggeber und Agenturen, die heute Verträge aufsetzen, müssen diese Ebenen mitdenken, damit ihre Projekte nicht innerhalb weniger Monate regulatorisch veraltet sind.
Ab dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz gemäß § 1 Abs. 3 BFSG zahlreiche B2C-Apps zur Einhaltung definierter Barrierefreiheitsanforderungen; deren Einhaltung ist durch Dienstleistungserbringer nach § 14 BFSG nachzuweisen und sollte vertraglich klar zugeordnet werden.
Konkret bedeutet das: Apps im Verbraucher-Kontext - von Banking- und E-Commerce-Apps bis zu Buchungs- und Kommunikationsanwendungen - unterliegen nach dem BFSG einem verbindlichen Barrierefreiheits-Regime. Der Vertrag sollte klar zuordnen, wer für die technische Umsetzung nach EN 301 549 oder WCAG 2.1 AA verantwortlich ist, wie Prüfung und Dokumentation erfolgen und wer für spätere Nachbesserungen haftet. Ein App-Vertrag ohne Barrierefreiheits-Klausel ist nach 2025 für B2C-Zwecke strukturell unvollständig.
Parallel entsteht mit der KI-Verordnung (Verordnung (EU) 2024/1689) eine eigene Compliance-Ebene für Apps mit KI-Funktionalität - von einfacher Chat-Integration bis zu Empfehlungssystemen. Der Vertrag sollte die Risikoklassifizierung der KI-Komponente, die Dokumentationspflichten der Agentur und die laufende Überwachung regeln. Für IoT- und Connected-Device-Apps wird zusätzlich der Data Act (Verordnung (EU) 2023/2854) relevant, der Datenzugangs- und Portabilitäts-Rechte der Nutzer vorsieht. Eine vertiefte Betrachtung KI-spezifischer Themen finden Sie auf unserer Seite zum KI-Vertrag.
BFSG-Compliance, AVV oder AI-Act-Einstufung - wir bringen Ihren App-Vertrag auf den neuen regulatorischen Stand.
Kostenlose Anfrage- Kostenlos beraten
- Kein Risiko, 100% vertraulich
Folgen eines ungeprüften App-Entwicklungsvertrags
Die wirtschaftlichen Folgen eines schwachen App-Vertrags treten selten als einmaliger Schaden auf. Sie kommen in Schichten - operativ, finanziell, reputativ - und die teuerste Schicht zeigt sich oft Monate nach dem geplanten Go-Live.
Operative Folgen: Release-Blockade, Wechsel-Unmöglichkeit, Bug-Abhängigkeit
Wenn der Store-Release wegen ungeklärter Policy-Verstöße blockiert ist, steht die gesamte Marketing- und Vertriebsplanung still. Die Pressemitteilung ist raus, Beta-Tester warten, Investoren haben den Termin im Kalender - aber die App ist in Review und die Agentur streitet über die Verantwortung für die Nachbesserung. Jede Woche Verzögerung produziert intern Kosten, die nicht in der ursprünglichen Projektkalkulation standen.
Wenn Quellcode und Accounts bei der Agentur verbleiben, wird jeder Wechsel zum Verhandlungsprojekt. Sicherheits-Patches können nicht eigenständig deployt werden. Das Android-Keystore-Passwort kennt nur die Agentur; ein Agentur-Wechsel zwingt den Auftraggeber zu einer neuen Bundle-ID und damit faktisch zu einem Relaunch - mit dem Verlust aller bisherigen Reviews, Installs und Nutzer-Ratings. In einer Marktphase, in der App-Store-Rankings über Erfolg und Misserfolg entscheiden, ist das ein irreversibler strategischer Schaden.
Hinzu kommt die operative Bug-Abhängigkeit: Wenn ein iOS-Major-Release neue Inkompatibilitäten produziert oder Google-Play-Policies nachgezogen werden und nur die Agentur Build, Test und Re-Submit steuern kann, entsteht eine dauerhafte Abhängigkeit, die bei jeder Vertragsverhandlung eingepreist wird.
Finanzielle Folgen: Rückabwicklung, Doppelfinanzierung, entgangener Gewinn
Wenn ein App-Projekt scheitert und der Auftraggeber zurücktreten muss, steht die Rückabwicklung bezahlter Anzahlungen im Raum. Bei einer solventen Agentur ist das schmerzhaft, aber machbar. Bei einer insolventen Agentur ist die Forderung zur Tabelle anzumelden, und die Quote in der Insolvenzmasse ist in der Regel sehr niedrig. Parallel läuft die Zeit: Wenn die App-Marketing-Kampagne bereits startet oder die nächste Finanzierungsrunde an einen Go-Live geknüpft ist, kostet jede Verzögerungswoche zusätzliches Geld.
Entgangener Gewinn durch verspätete Markteinführung einer App ist nach der Rechtsprechung der Oberlandesgerichte grundsätzlich ersatzfähig, wenn er hinreichend konkret durch Marktanalysen oder Umsatzprognosen nachweisbar ist; pauschale Gewinnerwartungen genügen nicht.
In vielen Fällen entstehen Doppelfinanzierungen: Der Auftraggeber zahlt ein zweites Entwickler-Team, um das ursprüngliche Projekt zu retten oder eine Neuentwicklung auf Basis rudimentärer Reste aufzusetzen. Die Gesamtkosten können dabei das ursprüngliche Budget um ein Mehrfaches übersteigen. Eine strukturell saubere Vertragsgestaltung vor Projektstart - mit Meilenstein-Kopplung, Escrow und klaren Ausstiegsrechten - ist immer günstiger als die nachträgliche Rettungsaktion.
Rechtliche und Compliance-Folgen
Die rechtliche Dimension wird im Startup- und Mittelstands-Umfeld häufig unterschätzt. Nicht erfüllte DSGVO-Pflichten können Bußgelder auslösen, deren Höhe sich am Umsatz des Verantwortlichen bemisst. Fehlende AVVs mit SDK-Anbietern treffen im Außenverhältnis den App-Betreiber, nicht die Agentur. Ab Mitte 2025 kann die fehlende BFSG-Konformität bei B2C-Apps zu Unterlassungs- und Beseitigungsansprüchen führen, die aus marktaufsichtsrechtlichen Verfahren erwachsen. Und bei KI-integrierten Apps wird mit der schrittweisen Anwendung der KI-Verordnung ein eigenes Pflichtenregime aufgebaut, dessen Verletzung ebenfalls sanktioniert ist.
Für Geschäftsführer ist dabei relevant: Die Einhaltung dieser Pflichten gehört zur Leitungsaufgabe. Wer einen App-Vertrag unterschreibt, der zentrale Compliance-Themen ungeregelt lässt, setzt sich persönlichen Haftungsrisiken aus - unabhängig davon, wie die Haftungsverteilung zwischen Auftraggeber und Agentur intern vereinbart ist.
Was ein belastbarer App-Entwicklungsvertrag regeln muss
Ein belastbarer App-Entwicklungsvertrag ist kein Template. Er ist ein modulares Dokument, in dem jedes Konfliktfeld eine eigene, präzise Regelung bekommt. Aus unserer Vertragspraxis haben sich die folgenden Bausteine als unverzichtbar erwiesen.
Leistungsbeschreibung und quantifizierte Acceptance-Kriterien
Die Leistungsbeschreibung ist das Fundament jedes Werkvertrags. Bei Apps heißt das konkret: Wireframes oder Figma-Referenzen als verbindlicher Anhang, Feature-Liste mit eindeutigen Identifikatoren, Ziel-Plattformen und OS-Versionen (zum Beispiel iOS 16 aufwärts, Android 12 aufwärts), Sprachversionen, unterstützte Geräte-Segmente und Backend-Schnittstellen. Ergänzend gehören messbare Acceptance-Kriterien in den Vertrag: Crash-Rate-Schwellen nach TestFlight-Beta, Performance-Baselines für Cold-Start und Listen-Rendering, API-Response-Zeiten, Speicherverbrauch, Barrierefreiheits-Niveau.
Abnahme-Logik mit realistischen Prüffristen
Die Abnahme sollte gestaffelt sein: Teilabnahmen pro Meilenstein mit begrenzter Wirkung auf die Schlussabnahme, Schlussabnahme nach vollständiger Feature-Komplettierung und erfolgreicher Store-Einreichung. Die Prüffrist pro Milestone sollte mindestens drei bis vier Wochen betragen - bei komplexen Apps länger. Der Vertrag sollte die Form der Abnahmeverweigerung regeln (schriftlich, mit Mangelauflistung), die Remedierungs-Frist für die Agentur und die Folgen bei erfolgloser Remedierung.
Mängelrechte und Rücktrittsvoraussetzungen
Die Mängelrechte aus §§ 634 ff. BGB - Nacherfüllung, Minderung, Rücktritt, Schadensersatz - sollten im Vertrag an die App-Realität angepasst sein. Mangel-Kategorien (Critical, Major, Minor) mit unterschiedlichen Reaktions- und Lösungszeiten, Regelungen zur Nacherfüllungsfrist nach § 635 BGB, Rücktrittsvoraussetzungen nach § 323 BGB und Schadensersatz nach § 281 BGB gehören in einen kohärenten Mechanismus.
Bei Individualsoftware ist die Nacherfüllungsfrist regelmäßig eher länger anzusetzen, weil gerade zu Beginn des Softwareeinsatzes Schwierigkeiten zu erwarten sind und die Mängelbeseitigung aufwendig sein kann.
Nutzungsrechts-Einräumung und Quellcode-Übergabe
Die Rechteklausel muss die Dimensionen Art (einfach oder ausschließlich), Umfang (Plattformen, Territorium, Bearbeitungs- und Unterlizenz-Rechte), Dauer und Vergütung sauber regeln. Ebenso gehört die Quellcode-Übergabe inklusive Build-Skripten, CI/CD-Konfiguration, Dokumentation und Dependency-Liste in die Rechteklausel - nicht als separate Nebenabrede.
Bei der Entwicklung einer App durch einen angestellten Entwickler stehen die Nutzungsrechte am entstandenen Computerprogramm nach § 69b UrhG im Zweifel dem Arbeitgeber zu, sofern das Programm in Erfüllung arbeitsvertraglicher Pflichten geschaffen wurde.
Für Agenturen, die mit freien Entwicklern arbeiten, ist zusätzlich relevant, dass die Rechtekette an den Auftraggeber nur dann vollständig ist, wenn auch die Freelancer ihre Rechte ordnungsgemäß einräumen - sonst entsteht beim Auftraggeber keine belastbare Rechteposition.
Store-Compliance, Accounts und Signing
Hier gehört die oben beschriebene Aufteilung in den Vertrag: Accounts und Signing-Identitäten auf Auftraggeber-Seite, Store-Policy-Referenzversion, Re-Submission-Regeln bei Rejection, Verantwortungszuordnung für Privacy Labels, Datenschutzerklärung und Marketing-Assets. Als Ergänzung empfiehlt sich eine Übergangs-Regelung für den Projektabschluss: dokumentierter Account-Übergang, Übergabe aller Build-Infrastruktur-Credentials, formale Beendigung der Agentur-Rollen.
Escrow, Insolvenz und Exit
Source-Code-Escrow als Drei-Parteien-Treuhand mit einem spezialisierten Anbieter ist für geschäftskritische Apps Standard. Die Herausgabe-Events (Insolvenzantrag, dauerhafte Nichterbringung, Vertragsende) sollten eindeutig formuliert sein, die Update-Frequenz des hinterlegten Quellcodes verbindlich geregelt. Ergänzend gehört eine Exit-Klausel in den Vertrag: Mitwirkung der Agentur bei der Übergabe an einen Nachfolger, Dokumentations-Verpflichtung, Fristen und Kosten für die Übergangsphase.
Datenschutz und AVV
Die AVV nach Art. 28 DSGVO ist als Anlage Bestandteil des Vertrags. Ergänzend müssen TOMs nach Art. 32 DSGVO verbindlich definiert sein, die Liste der eingesetzten SDKs dokumentiert und die Drittlandtransfer-Regelungen (insbesondere bei US-SDKs) belastbar. Die Verantwortung für Consent-Management, Datenschutzerklärung und Privacy Labels ist eindeutig zugeordnet.
Haftung, Versicherung und Vertragsstrafen
Eine faire Haftungsregelung beschränkt die Haftungshöhe für einfache Fahrlässigkeit, lässt aber Kardinalpflichten, Vorsatz, grobe Fahrlässigkeit und Personenschäden voll haftungsbelegt. Für definierte Pflichtverletzungen (Quellcode-Rückhaltung, Account-Verweigerung, Nichterfüllung der AVV) können pauschalierte Vertragsstrafen die Durchsetzung beschleunigen. Bei Agenturen empfiehlt sich die Pflicht zu einer ausreichenden Berufshaftpflicht- und Cyber-Versicherung mit Nennung des Auftraggebers als Bezugsberechtigten.
Abgrenzung zu SaaS, agiler Entwicklung und Framework-Projekten
App-Entwicklungsverträge enden dort, wo andere Vertragsfamilien beginnen. Reine SaaS-Angebote mit Dauerschuld-Mechanik und eigenem Verfügbarkeits-SLA behandeln wir auf der Seite zur Prüfung von SaaS-Verträgen. Iterative Eigenentwicklung nach Scrum oder Kanban mit offenem Scope folgt einer eigenen Logik rund um Sprint-SoWs, Definition of Done und Change-Request-Mechanik - dafür die Seite zum agilen Softwareentwicklungsvertrag. Individuelle Software ohne Mobile-Fokus ist Thema unserer Seite zum Softwarevertrag. Laufender IT-Betrieb nach Projektabschluss wird auf der Seite zum IT-Outsourcing-Rahmenvertrag behandelt. Bei hybriden Projekten stimmen wir die Vertragsfamilien aufeinander ab, statt eine Mischform entstehen zu lassen, die später auseinanderfällt.
Tipp von Rechtsanwalt Dr. Sener Dincer:
“Die meisten Mandanten kommen erst zu uns, wenn die Abnahme schon streitig ist oder die Agentur den Zugriff auf Quellcode und Signing-Zertifikate verweigert. Das ist spät, aber nie zu spät. Was wir vermeiden wollen, ist der nächste Fehler - eine unbedachte Teilabnahme per E-Mail, eine Schlusszahlung ohne Mangelrüge oder eine verfrühte Eskalations-Mail, die später als Zustimmung ausgelegt wird. Leiten Sie uns die Korrespondenz weiter, bevor Sie eine abschließende Erklärung abgeben - dann behalten wir den juristischen Spielraum, den wir brauchen.”
App-Entwicklungsvertrag vor der Unterschrift oder vor der Abnahme - wir setzen die Bausteine so auf, dass sie im Ernstfall halten.
Kostenlose Anfrage- Kostenlos beraten
- Kein Risiko, 100% vertraulich
Wenn das Projekt bereits eskaliert - unsere juristischen Hebel
Die meisten Konflikte rund um App-Entwicklungsverträge erreichen uns nicht vor der Unterschrift, sondern wenn die Abnahme verweigert wird, der Quellcode blockiert ist oder die Agentur die Kommunikation einstellt. Auch dort gibt es klare Hebel, die rein operativ nicht greifbar werden.
Prüfung der Abnahme-Situation und Abwehr der fiktiven Abnahme
Wenn die Agentur eine Milestone-Zahlung einfordert, obwohl die Leistung nach Ihrer Einschätzung nicht abnahmefähig ist, analysieren wir den Stand gegen die vertraglichen Acceptance-Kriterien. Wir formulieren eine belastbare Abnahmeverweigerung mit Mangelauflistung, setzen eine realistische Nacherfüllungsfrist und verhindern damit, dass über die fiktive Abnahme nach § 640 Abs. 2 BGB die Restvergütung fällig wird, ohne dass die App tatsächlich läuft.
Rücktritt, Schadensersatz und Rückforderung von Anzahlungen
Bei nicht heilbarer Nichtleistung prüfen wir die Voraussetzungen für den Rücktritt nach § 323 BGB und den Schadensersatz statt der Leistung nach § 281 BGB. Das umfasst Rückforderungsansprüche für geleistete Anzahlungen, Ersatz für unnütze Aufwendungen und bei entsprechend nachweisbarer Marktsituation auch entgangenen Gewinn aus der verpassten Markteinführung. Die Abstimmung mit Ihrem internen Controlling ist dabei entscheidend, damit der Schaden prozessfest dokumentiert ist.
Herausgabe von Quellcode, Zertifikaten und Account-Zugriff
Wenn die Agentur Quellcode, Signing-Zertifikate oder Plattform-Accounts zurückhält, prüfen wir die vertraglichen und urheberrechtlichen Grundlagen. Wo eine explizite Herausgabeklausel besteht, setzen wir sie durch - notfalls mit einstweiliger Verfügung. Wo keine ausdrückliche Klausel besteht, prüfen wir die Rückfall-Positionen aus Zweckübertragungsgrundsatz, § 69d UrhG (bestimmungsgemäße Nutzung) und werkvertraglichen Mitwirkungspflichten. Häufig lässt sich auch ohne perfekte Klausel eine belastbare Position erarbeiten.
Insolvenz der Agentur und Escrow-Durchsetzung
Bei Insolvenz der Agentur prüfen wir sofort die Escrow-Lage, die Anmeldung zur Insolvenztabelle und die Sicherung noch vorhandener Assets. Wenn kein Escrow besteht, versuchen wir den Zugriff auf Quellcode und Build-Infrastruktur über direkte Vereinbarung mit dem Insolvenzverwalter zu erreichen - meist gegen eine Ablösezahlung, deren Höhe wir auf Basis der Masse-Situation kritisch hinterfragen. Parallel koordinieren wir mit Ihrem IT-Team die Fortführung, damit die App technisch am Leben bleibt und keine Store-Compliance-Verstöße entstehen.
Vorsicht bei direkter Kommunikation mit der Agentur im Streitfall
Jede E-Mail und jedes Telefonat nach einer Abnahme- oder Eskalations- Situation kann später gegen Sie verwendet werden. Eine verfrühte Teilabnahme per Slack, eine unbedachte Mangel-Bagatellisierung oder eine Zustimmung “nur für interne Zwecke” engen den Verhandlungsspielraum massiv ein. Vor jeder direkten Reaktion lohnt sich eine kurze juristische Abstimmung - oft sind es die ersten 48 Stunden, in denen die entscheidenden Weichen gestellt werden.
So arbeiten wir an App-Entwicklungsverträgen
Jedes Mandat beginnt mit einer klaren Bestandsaufnahme - egal, ob Sie einen neuen App-Vertrag gestalten lassen, einen bestehenden prüfen lassen oder bereits in einer Eskalation stehen.
So läuft die Zusammenarbeit ab
- Kostenfrei
1. Ersteinschätzung
Wir sichten Werkvertrag, Lastenheft, Sprint-Kommunikation und den aktuellen Projektstand und markieren die kritischen Stellen.
-
2. Analyse und Strategie
Wir bewerten Rechtsnatur, Risiken, Verhandlungsspielraum und stimmen mit Ihnen das Ziel ab - Vertragsgestaltung, Nachverhandlung oder Eskalation.
-
3. Umsetzung
Wir gestalten den App-Vertrag neu, verhandeln mit der Agentur oder übernehmen die außergerichtliche und gerichtliche Durchsetzung.
-
4. Ergebnis
Sie erhalten einen belastbaren Vertrag oder eine klare Lösung im Streit - mit dokumentierter Argumentation, auf die Sie auch in späteren Releases zurückgreifen können.
Warum Eigenversuche im App-Kontext besonders oft scheitern
Viele Mandanten haben vor uns versucht, den Konflikt mit der App-Agentur intern zu lösen - im direkten Dialog mit dem Projektleiter, per E-Mail-Austausch mit dem Agentur-Geschäftsführer oder mit einem nicht-spezialisierten Hausanwalt. Das Ergebnis ist in der Mehrzahl der Fälle das gleiche: Die entscheidenden juristischen Hebel werden nicht gezogen, weil sie den Beteiligten nicht vertraut sind. Gleichzeitig entsteht in den ersten Gesprächen oft Kommunikation, die später nicht mehr zurückgenommen werden kann - eine Slack-Nachricht, die als Teilabnahme ausgelegt wird, eine Schlusszahlung ohne Mangelrüge, eine E-Mail mit der Formulierung “grundsätzlich einverstanden”.
Wir bringen nicht nur die juristische Argumentation ein, sondern auch die Erfahrung, welche Klauseln in App-Entwicklungsverträgen wie belastbar sind und wie App-Agenturen typischerweise auf verschiedene Eskalationsstrategien reagieren. Das verkürzt die Verhandlung und vermeidet Fehler, die sich später nur noch mit Prozessrisiken auffangen lassen.
| Kriterium | Eigenversuch | Mit unserer Kanzlei |
|---|---|---|
| Vertragsprüfung | Fokus meist nur auf Preis, Timeline und Feature-Liste | Prüfung aller Bausteine: Werkvertrag-Struktur, Abnahme, Nutzungsrechte, Store-Accounts, Escrow, AVV, Haftung, Exit |
| Abnahme und Mängelrüge | Informelle Kommunikation führt oft zur fiktiven Abnahme | Formal belastbare Mangelrüge mit Acceptance-Kriterien und Nacherfüllungsfrist |
| Quellcode und Accounts | Durchsetzung scheitert an fehlender Klausel oder schwacher Rückfall-Position | Gezielte Durchsetzung über Rechteklausel, § 69 UrhG und werkvertragliche Mitwirkungspflichten |
| Agentur-Insolvenz | Totalverlust des Projekts bei fehlendem Escrow | Sicherung der Assets über Insolvenzverwalter und Escrow-Durchsetzung |
| Kommunikation | Selbstkompromittierend - E-Mails werden später im Streit verwendet | Strukturierte, prozessual belastbare Korrespondenz |
Die Ersteinschätzung ist bei uns kostenfrei. Auf Basis Ihrer Unterlagen prüfen wir den Sachverhalt und unterbreiten Ihnen anschließend ein transparentes Angebot mit klaren Leistungsbausteinen, damit Sie die Kostenseite planen können, bevor Sie uns mandatieren.
Nächste Schritte
App-Entwicklungsverträge sind keine Formalien. Sie sind die vertragliche Grundlage für Produkte, die oft die ganze Wertschöpfungskette eines Unternehmens tragen - vom direkten B2C-Kontakt über die Kundenbindung bis zur Datenstrategie. Sie bestimmen, wer bei Streit, Wechsel oder Agentur-Insolvenz welche Rechte hat - und ob die App als geschäftskritisches Asset in Ihrem Einflussbereich bleibt oder zur dauerhaften Abhängigkeit wird.
Wir strukturieren App-Entwicklungsverträge so, dass Sie als Auftraggeber im Ernstfall nicht überrascht werden. Bei Neugestaltung heißt das: Werkvertrag, Abnahme, Nutzungsrechte, Store-Ownership, Escrow und Exit als zusammenhängendes System. Bei laufenden Konflikten heißt das: die richtige Reihenfolge aus Mangelprüfung, Fristsetzung, Verhandlung und - wenn nötig - gerichtlicher Durchsetzung.
In einem kostenfreien Erstgespräch prüfen wir Ihre Unterlagen, ordnen die Ausgangslage ein und zeigen Ihnen die nächsten sinnvollen Schritte. Auf dieser Basis entscheiden Sie, wie Sie weiter vorgehen wollen - wir liefern die Einordnung, Sie behalten die Kontrolle.