App-Entwicklungsvertrag Checkliste: Was vor der Unterschrift klar sein 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:

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?

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:

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

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)