App-Vertrag Checkliste vor der Unterschrift

Dieser Artikel ist eine praktische Checkliste für App-Verträge: Scope, Abnahmekriterien, Meilensteinzahlungen, Change Requests, Code-Eigentum, Support nach dem Launch und Exit-Plan. Ziel: Klarheit, Kontrolle und weniger Streit—bevor das Projekt startet.

Checkliste für App-Entwicklungsverträge: Was Sie vor der Unterschrift prüfen sollten

Wenn es einen Satz gibt, der die Zukunft Ihres App-Projekts bestimmt, dann ist es dieser: "Der Vertrag ist die schriftliche Version der Realität."

Selbst großartige Ideen, Designs und Teams helfen Ihnen nicht weiter, wenn sie nicht ordentlich auf dem Papier festgehalten sind. Die meisten Projekte, die "teurer als erwartet" oder "länger als versprochen" werden, haben kein technisches Problem – ihr Problem ist, dass von Anfang an nicht klar war, was genau geliefert werden soll, wann, in welcher Qualität und mit welchem Mechanismus für Änderungen.

Wenn Sie sich noch in der Entscheidungsphase befinden, sollten Sie zunächst die Roadmap für die App-Bestellung durchgehen, um zu wissen, welche Fragen Sie stellen und welche Ergebnisse Sie erwarten sollten:

https://www.olymaris.com/de/blog/ordering-an-app-a-professional-roadmap-for-clients

Und wenn Sie noch unsicher sind, ob Sie eine Native-, Hybrid- oder Web-App möchten, hat diese Wahl auch direkte Auswirkungen auf den Vertrag (Zeit, Kosten, Tests, Store, Veröffentlichung):

https://www.olymaris.com/de/blog/native-hybrid-or-web-app-which-one-is-right

Dieser Artikel wurde geschrieben, damit Sie die Klauseln, die normalerweise später Probleme verursachen, von Anfang an klären können, bevor Sie auch nur einen Euro ausgeben. Das Ergebnis ist ein "durchsetzbarer" Vertrag, keine Datei voller schöner Sätze.

Teil 1: Drei häufige Fehler, die den Vertrag von Anfang an ruinieren

Fehler 1: Vertrag ohne genaue Scope-Definition

Wenn der Arbeitsumfang unklar ist, kann jede neue Anforderung als "Teil des Projekts" betrachtet werden. Hier verbrennen Zeit und Kosten. Wenn Sie die Risiken genauer sehen möchten, lesen Sie unbedingt diesen Artikel:

https://www.olymaris.com/de/blog/10-common-app-project-risks-that-burn-time-and-budget

Fehler 2: Zeitplanung aus der Luft gegriffen

"In drei Monaten fertig" muss, wenn es zum Vertrag wird, mit genauen Annahmen geschrieben werden: Anzahl der Seiten/Bildschirme, Komplexität der Rollen, Admin-Panel, Online-Zahlung, Chat, Benachrichtigungen, Mehrsprachigkeit usw. Für eine realistische Zeitleiste:

https://www.olymaris.com/de/blog/how-long-does-it-take-to-build-a-website-or-app-a-realistic-timeline

Fehler 3: Zahlung ohne messbare Lieferung

Wenn Zahlungen nicht an messbare Lieferungen gekoppelt sind, sind Konflikte unvermeidlich: Der Kunde sagt "es ist noch nicht fertig", der Auftragnehmer sagt "gemäß der geleisteten Arbeit muss bezahlt werden". Von Anfang an müssen Liefer- und Abnahmekriterien klar sein.

Teil 2: Checkliste der kritischen Vertragsklauseln (was festgelegt werden muss)

Definition der Parteien, Rollen und offizieller Kommunikationskanal

Wer sind genau die Vertragsparteien? Unternehmen/Person, Registrierungsnummer, Adresse, verantwortlicher Vertreter.
Eine Person auf Kundenseite sollte "Product Owner" oder endgültiger Entscheidungsträger sein.
Eine Person vom Umsetzungsteam sollte "Project Manager" oder technisch Verantwortlicher sein.
Der offizielle Kommunikationskanal sollte festgelegt werden (z.B. E-Mail + ein Projektmanagement-Tool). Verstreute WhatsApp-Nachrichten werden später keine Beweise sein.

Ziel und finales Ergebnis des Projekts (Outcome), nicht nur Features

Anstatt nur eine Feature-Liste zu schreiben, definieren Sie auch das Ziel des Ergebnisses:

Für welche Art von Benutzer ist die App?
Was ist der Hauptweg des Benutzers?
Was ist das anfängliche Erfolgskriterium? (z.B. Registrierung, Bestellung, Buchung, Zahlung)

Dies stellt sicher, dass bei Entscheidungen während des Projekts "die Hauptgeschichte" nicht vergessen wird.

Scope / Genauer Arbeitsumfang (mit beigefügten Dokumenten)

Hier sollten die Anhänge entscheidend sein:

PRD oder SOW: Anforderungsdokument (auch einfach und leicht)
Wireframe oder gestaltetes UI
Liste der Rollen und Zugriffsebenen
Plattformen: iOS, Android, Web Admin usw.
Sprachen und Länder
Zusätzliche Dienste: Zahlung, SMS, E-Mail, Karte, Analytics, Chat, CRM usw.

Wenn Sie Kosten schätzen, empfehle ich Ihnen auch diesen Preisleitfaden, um zu verstehen, wie sich jeder Teil auf den Preis auswirkt:

https://www.olymaris.com/de/blog/how-much-does-it-cost-to-build-an-app-a-pricing-guide-for-small-and-medium-businesses

Wichtiger Hinweis:

Schreiben Sie auch "Punkte außerhalb des Scope" auf. Viele Konflikte entstehen, weil der Kunde annimmt "das ist selbstverständlich", aber das Umsetzungsteam betrachtet es als außerhalb des Vertrags. Beispiel: Content-Erstellung, Dateneingabe, Lizenzkauf, Serverkosten, ASO, Werbung, Fotografie usw.

Definition der Lieferung und Abnahmekriterien (Definition of Done + Acceptance Criteria)

Dieser Abschnitt sollte wie eine Checkliste sein:

Welche Bedingungen muss jede Funktion erfüllen, um als "geliefert" zu gelten?
Auf welchen Geräten/Versionen werden Tests durchgeführt?
Wie hoch sollte die Mindestleistung sein?
Was umfasst die Basissicherheit? (z.B. Kommunikationsverschlüsselung, Passwortrichtlinie, Protokollierung sensibler Ereignisse)
Was sind akzeptable Fehler?

Professioneller Vorschlag:

Legen Sie eine formelle UAT-Phase (User Acceptance Testing durch den Kunden) fest. Zum Beispiel: "Nach Lieferung jedes Meilenstein hat der Kunde 7 Werktage zum Testen und zur Meldung von Mängeln/Nichtannahme, andernfalls gilt die Lieferung als akzeptiert." Diese Klausel ist sowohl für den Kunden gut (hat das Recht zu testen) als auch für das Umsetzungsteam (das Projekt bleibt nicht in endlosen Tests stecken).

Realistische Zeitplanung + Annahmen

Die Zeitleiste muss mit Annahmen einhergehen:

Wann liefert der Kunde Inhalte/Zugriffe/Entscheidungen?
Wie lang ist die Reaktionszeit des Kunden?
Wenn die Reaktion oder Entscheidungsfindung verzögert wird, verschiebt sich die Zeitleiste entsprechend.

Dieser Satz muss klar sein: "Verzögerungen aufgrund mangelnder Zusammenarbeit/rechtzeitiger Reaktion des Auftraggebers werden zur Projektzeitleiste hinzugefügt."

Gesundes Zahlungsmodell (Meilenstein-basiert)

Gute Zahlung bedeutet Zahlung proportional zum Risiko. Gängiges und gesundes Muster:

Vorauszahlung für Start und Kapazitätsreservierung des Teams
Stufenzahlungen nach Lieferung jedes Meilensteins
Kleiner Prozentsatz als Holdback bis nach Launch/anfänglicher Stabilität

Dieses Modell gibt dem Kunden ein Gefühl der Sicherheit und dem Umsetzungsteam einen vorhersehbaren Cashflow.

Änderungsmanagement (Change Request) mit klarer Formel

Kein Projekt kommt ohne Änderungen aus. Das Problem entsteht, wenn Änderungen kostenlos und endlos werden. Im Vertrag festlegen:

Änderungsanträge müssen schriftlich erfolgen
Das Umsetzungsteam gibt die Auswirkung der Änderung auf Kosten und Zeit an
Die Umsetzung beginnt erst nach schriftlicher Bestätigung des Kunden
Änderungen können auf zwei Arten bepreist werden: stündlich/täglich oder pauschal pro Änderung

Wenn Sie die Risiken von Änderungen genau sehen möchten, hilft dieser Artikel sehr:

https://www.olymaris.com/de/blog/10-common-app-project-risks-that-burn-time-and-budget

Eigentum und Zugriffe (IP, Repos, Accounts)

Hier muss präzise und emotionslos geschrieben werden, da dies später der sensibelste Punkt ist:

Eigentum an UI/UX-Dateien (Figma und Ausgaben)
Eigentum am Quellcode und Übergabe des Repositories (Git)
Veröffentlichungskonten (Apple Developer / Google Play / Firebase / ...)
Zugriffe und Zugriffsebenen

Gängiges und logisches Modell, das Konflikte reduziert:

"Eigentum am Quellcode und vollständige Übertragung der Zugriffe erfolgt nach vollständiger Abrechnung und Zahlung der Vertragsbeträge." Dies ist sowohl geschäftlich vertretbar (kein Verkäufer überträgt vor vollständiger Abrechnung das vollständige Eigentum) als auch für den Kunden transparent.

Verwendung von vorgefertigten Komponenten und Lizenzen

Wenn das Projekt Bibliotheken, Vorlagen oder lizenzierte Dienste verwendet:

Bei welcher Partei liegen die Lizenzkosten?
Auf wessen Namen wird die Lizenz registriert?
Wenn die Lizenz nicht verlängert wird, welcher Teil der App funktioniert nicht mehr?

Transparenz hier verhindert spätere Ansprüche.

Garantie (Warranty) und Fehlerbehebung

Verwechseln Sie nicht zwei Dinge: "Bug" und "Änderungsantrag".

Bug bedeutet: etwas, das laut Vertrag funktionieren sollte, aber nicht funktioniert
Änderung bedeutet: Hinzufügen/Entfernen oder Ändern des Verhaltens gegenüber der ursprünglichen Vereinbarung

Im Vertrag schreiben:

Wie lang ist die Garantiezeit für Fehlerbehebung nach endgültiger Lieferung? (z.B. 30 bis 60 Tage)
Mit welcher Priorität und in welchem SLA werden Bugs behoben?
Änderungen und neue Entwicklungen liegen außerhalb der Garantie und werden separat geschätzt

Support nach dem Launch (Support & Maintenance)

Viele sehen nur die Baukosten, nicht die Kosten nach dem Launch. Dieser Abschnitt sollte transparent sein:

Überwachung von Abstürzen und Fehlern
Updates für neue iOS/Android-Versionen
Backup und Serverwartung
Sicherheit und Patches
Kleine Verbesserungen

Sie können zwei Pläne definieren: Basic und Pro, mit festgelegten Stunden pro Monat.

Leistung, Sicherheit und Verantwortlichkeiten (Responsibility Boundaries)

Dieser Abschnitt muss realistisch sein:

100% Sicherheit gibt es nicht, aber Grundstandards müssen eingehalten werden
Die Verantwortung für Ereignisse außerhalb der Kontrolle des Umsetzungsteams muss klar sein (z.B. Ausfall von Drittanbieterdiensten, API-Sanktionen, plötzliche Änderungen der Store-Regeln)
Wenn der Kunde Zahlungsverzug hat, hat das Umsetzungsteam das Recht, die Arbeit einzustellen? (Diese Klausel muss klar sein, damit das Projekt nicht in einem Graubereich bleibt)

Haftungsbeschränkung (Limitation of Liability) und Schadensersatz

Diese Klausel ist normalerweise für beide Parteien wichtig, damit das Projekt nicht zu einer Rechtskrise wird:

Obergrenze der finanziellen Haftung der Parteien
Dass indirekte Schäden (wie entgangener potenzieller Gewinn) normalerweise nicht geltend gemacht werden können

Wenn diese Klausel richtig geschrieben ist, kontrolliert sie das Risiko und hält die Entscheidungsfindung rationaler.

Exit-Plan oder sichere Übergabe

Selbst wenn die Zusammenarbeit ausgezeichnet ist, muss der Exit-Weg standardisiert sein:

Wenn das Projekt halbfertig gestoppt wird, was wird geliefert?
Was ist die Mindestdokumentation?
Wie wird der Code- und Deployment-Status übergeben?
Wie werden Zugriffe übertragen?

Das Vorhandensein eines Exit-Plans stellt sicher, dass sich keine Partei als Geisel fühlt und der Kooperationsraum gesund bleibt.

Dokumentation und Schulung

Für Anwendungen ist eine kleine, aber echte Dokumentation erforderlich:

Admin-Panel-Anleitung
Anleitung zur Veröffentlichung von Versionen
Erklärung der allgemeinen Architektur und Dienste
Liste der Drittanbieterdienste und Schlüssel (ohne Sicherheitsoffenlegung im öffentlichen Text)

Teil 3: 12 Warnzeichen (Red Flags) vor der Unterschrift

Dies sind Dinge, bei denen Sie innehalten sollten, wenn Sie sie in Verhandlungen sehen:

❌ Vertrag ohne Scope-Anhang (nur ein paar Seiten allgemeiner Text)

❌ Versprechen sehr kurzer Zeit ohne Anforderungsprüfung

❌ Vollständige Zahlung vor jeder Lieferung

❌ Kein Change-Request-Mechanismus

❌ Keine Definition von UAT und Abnahmekriterien

❌ Unklares Code- und Kontoeigentum

❌ Kein Support-Plan nach dem Launch

❌ Drängen auf schnellen Start ohne PRD oder mindestens Wireframe

❌ Versprechen "alles ist drin" ohne genaue Definition

❌ Kein Project Manager/Verantwortlicher

❌ Ignorieren von Risiken und Tests

❌ Keine Transparenz über Drittanbieterkosten (Server, SMS, Karte, Lizenzen)

Wenn Sie sich noch in der Ideenvalidierungsphase befinden, hilft diese Checkliste zu verstehen, ob es sich überhaupt lohnt zu bauen:

https://www.olymaris.com/de/blog/10-signs-your-app-idea-is-worth-building-full-checklist

Und wenn Sie zwischen der Wahl des App-Typs und des Entwicklungswegs unentschlossen sind, halten Sie diesen Artikel griffbereit, da er direkte Auswirkungen auf den Vertrag hat:

https://www.olymaris.com/de/blog/native-hybrid-or-web-app-which-one-is-right

Teil 4: Ein einfaches Muster für den Scope-Anhang (damit der Vertrag "durchsetzbar" wird)

Wenn Sie möchten, dass Ihr Vertrag praktisch und vertretbar ist, reicht auch ein einseitiger Anhang, vorausgesetzt er ist präzise:

• Liste der Rollen: Admin / Kunde / Mitarbeiter / ...
• Liste der Seiten/Bildschirme (z.B. 20 Bildschirme)
• Hauptabläufe: Registrierung, Login, Zahlung, Bestellung, Benachrichtigungen
• Integrationen: Payment, SMS, Maps, Analytics
• Plattformen: Android + iOS + Admin Panel
• Sprachen: Englisch/Deutsch (falls erforderlich)
• Außerhalb des Scope: Content-Erstellung, Werbung, ASO, Servicekosten, Dateneingabe usw.

Dieser Anhang verwandelt den Vertrag von einem allgemeinen Text in ein Projektkontrollwerkzeug.

Zusammenfassung

Ein guter Vertrag soll die Beziehung nicht erschweren; er soll die Beziehung transparent machen.

Wenn Scope, Lieferkriterien, Änderungen, Zahlung, Eigentum und Support von Tag eins an klar sind, schreitet das Projekt schneller voran, Konflikte werden weniger und beide Parteien verstehen "wie sie gewinnen".

Wenn Sie den Vertrag und den Scope-Anhang vor der Unterschrift einmal aus technischer und praktischer Sicht überprüfen möchten (ohne rechtliche Verkomplizierung), können Sie mit dieser Roadmap beginnen und Schritt für Schritt vorgehen:

https://www.olymaris.com/de/blog/ordering-an-app-a-professional-roadmap-for-clients

Häufig gestellte Fragen (FAQ)

Frage 1: Was ist das beste Zahlungsmodell für einen App-Entwicklungsvertrag?

Stufenzahlung basierend auf Meilensteinen und messbarer Lieferung, zusammen mit einem kleinen Holdback-Prozentsatz bis nach dem Launch, ist normalerweise das sicherste Modell.

Frage 2: Wie wird das Eigentum am Quellcode im App-Entwicklungsvertrag festgelegt?

Das gängigste Modell ist, dass der Kunde nach vollständiger Abrechnung Eigentum und vollständigen Zugriff auf das Code-Repository und die Konten erhält.

Frage 3: Was ist der Unterschied zwischen Bug und Änderung (Change Request)?

Bug bedeutet: etwas, das laut Vereinbarung funktionieren sollte und nicht funktioniert; Change Request bedeutet: Änderung oder Hinzufügung von etwas außerhalb der ursprünglichen Vereinbarung, das separat geschätzt werden muss.

Frage 4: Welche Rolle spielt UAT oder User Acceptance Testing im Vertrag?

UAT ist ein formeller Zeitraum für Kundentests, um die Lieferung jeder Phase zu bestätigen oder Mängel zu erfassen; das Fehlen von UAT führt zu langwierigen Konflikten.

Frage 5: Was genau sollte der Vertrag als Scope festlegen?

Rollen, Seiten/Bildschirme, Hauptbenutzerabläufe, Zusatzdienste, Plattformen, Sprachen und Punkte außerhalb des Scope müssen klar sein.

Frage 6: Was passiert, wenn der Kunde verspätet antwortet oder Entscheidungen trifft?

Im Vertrag sollte festgehalten werden, dass Verzögerungen aufgrund mangelnder Kundenzusammenarbeit zur Projektzeitleiste hinzugefügt werden.

Frage 7: Wie lang ist normalerweise die Garantiezeit für Fehlerbehebung nach endgültiger Lieferung?

Je nach Projekt ist es üblich, 30 bis 60 Tage für die Behebung von Bugs im Zusammenhang mit dem vereinbarten Scope vorzusehen.

Frage 8: Wer trägt die Kosten für Drittanbieterdienste wie Server, SMS oder Karten?

Dies muss im Vertrag klar festgelegt werden; normalerweise liegen die Kosten für Drittanbieterdienste und Lizenzen beim Kunden, sofern nicht anders vereinbart.

Frage 9: Was bedeutet Exit-Plan im App-Entwicklungsvertrag?

Es bedeutet, dass bei Beendigung der Zusammenarbeit klar ist, was geliefert wird: Code, Dokumentation, Zugriffe und Deployment-Status, damit das Projekt nicht scheitert.

Frage 10: Wie erkennen wir, ob die vorgeschlagene Zeitleiste realistisch ist?

Die Zeitleiste muss mit Annahmen einhergehen (Anzahl der Seiten, Rollen, Integrationen, Tests und Kundenreaktion). Versprechen ohne Annahmen sind nicht vertrauenswürdig.

App-Entwicklungsvertrag Checkliste: Was vor der Unterschrift klar sein muss