Der Vertrag für eine App-Entwicklung ist das Dokument, das man hoffentlich nie wieder braucht – und wenn doch, fehlt ausgerechnet der Satz, auf den es ankommt. Dieser Artikel ist keine Rechtsberatung: Wie Klauseln zu formulieren sind und was in deinem Fall gilt, gehört zu einer Anwältin oder einem Anwalt. Er ist eine Liste der Punkte, die aus Sicht eines Auftraggebers im Vertrag geregelt sein sollten – damit du weißt, wonach du fragst.
1. Was genau gebaut wird
Die Leistungsbeschreibung ist das Herz des Vertrags. Sie sollte so konkret sein, dass ein Dritter daraus erkennen kann, was fertig heißt: welche Funktionen, welche Plattformen, welche Sprachen, welche Geräte. Und – mindestens so wichtig – was nicht enthalten ist. Ein Satz wie „Login über Apple und Google ist nicht Teil des Umfangs“ kann dir ein Missverständnis ersparen, das später teuer wird.
Dazu gehört ein geregelter Weg für Änderungen: Wie wird ein Wunsch, der während des Projekts entsteht, bewertet, bepreist und beauftragt? Ohne diesen Weg kann jede Änderung zur Diskussion werden. Wie du die Beschreibung vorbereitest, steht in „So bereitest du dein App-Projekt vor“.
2. Zeitplan und Zwischenstände
Nicht nur ein Enddatum, sondern Etappen: Wann gibt es den ersten klickbaren Stand, wann eine Testversion auf deinem Handy, wann den Store-Release? Zwischenstände schützen vor der Überraschung am Ende: Wer regelmäßig eine Testversion bekommt, sieht Abweichungen früh – und nach unserer Erfahrung ist die Korrektur dann weniger Aufwand.
3. Der Zahlungsplan
Zahlungen an Etappen koppeln, nicht an Kalenderdaten: ein Teil zum Start, Teile bei Zwischenständen, der Rest bei Abnahme. So ist für beide Seiten geregelt, was wann fällig ist. Warum wir eine Anzahlung für fair halten, die komplette Summe vorab aber für ein Ungleichgewicht, steht in „Woran du ein seriöses App-Angebot erkennst“.
4. Abnahme – wann ist fertig fertig?
Der Vertrag sollte sagen, woran die Abnahme gemessen wird (die Leistungsbeschreibung), wie lange du Zeit zum Prüfen hast, und wie mit Mängeln umgegangen wird: welche verhindern die Abnahme, welche werden nach der Abnahme behoben. Ohne diese Regel kommt die Frage „ist das ein Mangel oder ein Änderungswunsch?“ leicht erst dann auf, wenn beide Seiten müde sind.
5. Die Rechte am Code
Der Punkt, bei dem sich Nachfragen am meisten lohnt. Als allgemeine Orientierung, Stand 2026: Computerprogramme sind nach § 69a UrhG geschützte Werke, soweit sie eine eigene geistige Schöpfung sind. Urheber ist nach § 7 UrhG der Schöpfer des Werkes, und das Urheberrecht selbst ist nach § 29 Abs. 1 UrhG außerhalb von Erbfällen nicht übertragbar. Vertraglich eingeräumt werden deshalb Nutzungsrechte (§ 29 Abs. 2, § 31 UrhG) – einfach oder ausschließlich, mit genau den Beschränkungen, die im Vertrag stehen. Dass du den Code auch bearbeiten darfst, ist kein Automatismus: § 69c Nr. 2 UrhG nennt die Bearbeitung und Umarbeitung eines Programms ausdrücklich als Handlung, die dem Rechtsinhaber vorbehalten ist.
Nicht verwechseln: § 69b UrhG betrifft angestellte Entwickler – schafft ein Arbeitnehmer das Programm in Wahrnehmung seiner Aufgaben oder nach Anweisung des Arbeitgebers, ist der Arbeitgeber zur Ausübung der vermögensrechtlichen Befugnisse berechtigt, sofern nichts anderes vereinbart ist. Das regelt das Verhältnis zwischen Entwickler und Arbeitgeber, nicht dein Auftragsverhältnis zum Dienstleister. Deine Rechte kommen aus deinem Vertrag.
Klär also im Vertrag: Welche Nutzungsrechte erhältst du, sind sie ausschließlich, darfst du den Code ändern und von anderen weiterentwickeln lassen, darfst du die Rechte weitergeben – etwa an einen Käufer deiner Firma? Steht dazu nichts drin, frag danach, bevor du unterschreibst. Wie weit die Rechte in deinem Fall reichen sollten und wie die Klausel zu fassen ist, beurteilt eine Anwältin oder ein Anwalt.
Was du vom Auftragnehmer verlangen kannst, ist eine klare Antwort. Bei uns steht sie in jedem Angebot: Am Code, den wir für dich schreiben, räumen wir dir mit der Schlusszahlung die Nutzungsrechte ein – einschließlich des Rechts, ihn zu bearbeiten und von anderen weiterentwickeln zu lassen. Für fremde Bausteine gelten deren eigene Lizenzen (Punkt 7).
Dazu gehört die Herausgabe des Quellcodes: spätestens mit der Schlusszahlung, zusammen mit Signaturschlüsseln und einer Dokumentation, was wo liegt – so ist es üblich und für beide Seiten fair. Bis dahin solltest du jeden Zwischenstand als Testversion auf deinem Handy sehen. Und der Vertrag sollte sagen, was bei einem vorzeitigen Ende mit bereits bezahlten Etappen geschieht.
6. Konten auf deinen Namen
Apple-Entwicklerkonto, Google-Play-Konto, Firebase- oder Supabase-Projekt, Domain, Drittanbieter-Dienste: Alles, was die App zum Laufen braucht, sollte auf dich oder deine Firma laufen, mit dir als Inhaber und dem Dienstleister als eingeladenem Nutzer – nicht umgekehrt. (Stand 2026: Ein echtes Team-Mitglied im Apple-Entwicklerprogramm setzt ein Organisationskonto voraus.) Der Vertrag kann das ausdrücklich festhalten. Warum das entscheidend ist, wenn sich die Wege trennen, zeigt „App übernehmen, wenn der Entwickler weg ist“ – jeder Punkt in dessen Checkliste ist ein Punkt, der in den Vertrag gehört.
7. Fremde Bausteine
In jeder App, die wir bauen, stecken Bausteine anderer – Open-Source-Bibliotheken, SDKs, Schriften. Der Vertrag sollte regeln, dass eingesetzte Bausteine unter Lizenzen stehen, die deine Nutzung erlauben, und dass du eine Liste davon bekommst. Ob eine bestimmte Lizenz zu deinem Vorhaben passt, bewertet im Zweifel juristischer Rat – die Liste ist die Voraussetzung dafür.
8. Daten und Zugriffe
Hat der Dienstleister während der Entwicklung oder Wartung Zugriff auf personenbezogene Daten deiner Nutzer, ist das ein Datenschutzthema für sich. Zur Orientierung, Stand 2026: Art. 28 Abs. 3 DSGVO sieht vor, dass die Verarbeitung durch einen Auftragsverarbeiter „auf der Grundlage eines Vertrags oder eines anderen Rechtsinstruments“ erfolgt. Ob dein Fall darunterfällt und wie die Vereinbarung aussehen muss, beurteilt ein Datenschutzbeauftragter oder juristischer Rat – wir liefern die technischen Angaben: welche Daten, welche Dienste, welche Zugriffe. Die technische Seite beschreibt „DSGVO in Apps“. Dazu eine Vertraulichkeitsregel für alles, was der Dienstleister über dein Geschäft erfährt.
9. Was nach dem Release passiert
Die App ist fertig – und dann? Der Vertrag sollte sagen, ob und wie Fehler nach der Abnahme behoben werden, und was Wartung kostet, wenn du sie willst. Am besten steht die Wartung in einem eigenen Vertrag, dessen Inhalt du kennst › „Was in einen App-Wartungsvertrag gehört“. Und ein Wort zur Trennung: Wie läuft eine Übergabe, wenn einer von beiden nicht weitermachen will? Diese Frage in guten Zeiten zu klären, erspart dir die Diskussion in schlechten.
Was hier absichtlich fehlt
Haftung, Gewährleistungsfristen, Vertragsstrafen, Kündigungsrechte, anwendbares Recht – das sind die Punkte, bei denen Formulierungen entscheiden, und genau deshalb gehören sie zu deinem Anwalt. Wir formulieren keine Vertragsklauseln und bewerten auch keine, die dir vorliegen – das ist juristische Arbeit. Diese Liste soll das Gespräch mit deinem Anwalt vorbereiten, nicht ersetzen.
Fazit
Ein guter Vertrag beantwortet neun Fragen, bevor sie gestellt werden: Was wird gebaut, wann sehe ich Zwischenstände, wann zahle ich, wann ist es fertig, was darf ich mit dem Code, wem gehören die Konten, welche fremden Bausteine stecken drin, wie ist der Datenschutz geregelt, und was passiert danach. Wer diese Liste zum Erstgespräch mitbringt, muss die Fragen nicht später stellen – wenn die Antwort unangenehm wird.
Angebot und Vertrag bekommst du bei uns vor der Unterschrift zum Lesen; welcher dieser Punkte bei uns wie geregelt ist, beantworten wir dir im kostenlosen Erstgespräch. Wir antworten werktags innerhalb von 24 Stunden.