MVP-Entwicklungsunternehmen: Fragen zum Code-Eigentum

Über Code-Eigentum wird oft erst am Ende eines Softwareprojekts gesprochen, wenn ein Anbieterwechsel dringend wird. Für Gründer, die mit einem MVP-Entwicklungsunternehmen arbeiten, gehört das Thema in das erste kommerzielle und operative Gespräch. Eigentum ist nicht nur eine Rechtsformel: Es bedeutet, das Produkt zu verstehen, zu betreiben, zu ändern, zu sichern und zu übergeben.

Das Ziel ist nicht, Gründer zu Ingenieuren zu machen. Das Unternehmen soll sein Produkt weiter betreiben können, ohne von einer Person, einem Lieferantenkonto oder einem undokumentierten Prozess abhängig zu sein.

Eigentum und Zugriff trennen

Stellen Sie zwei Fragen: Welche geistigen Eigentumsrechte werden übertragen oder lizenziert? Und welche Personen und unternehmenskontrollierten Konten können tatsächlich auf Code, Cloud-Dienste, Domains, Analytics, Zahlungsdienste, App-Stores und Design-Dateien zugreifen? Eine Vertragsantwort ohne Zugriff kann ein Unternehmen trotzdem blockieren.

Besprechen Sie diese Punkte mit passenden rechtlichen und technischen Beratern. Ein Entwicklungspartner darf seinen Prozess erklären, sollte aber nicht allein einen kommerziellen Vertrag im Namen des Gründers auslegen.

Konten vor dem Start inventarisieren

Erstellen Sie eine Liste aller vom MVP genutzten Dienste und nennen Sie den Kontoinhaber. Legen Sie nach Möglichkeit Unternehmenskonten an und geben Sie dem Delivery-Team passende Rechte, statt zentrale Dienste unter einer persönlichen oder Lieferantenidentität zu führen.

Asset oder Konto	Zu klärende Frage
Quell-Repository	Wer besitzt die Organisation und Admin-Rechte?
Cloud und Hosting	Welches Unternehmenskonto erhält Rechnungen und kontrolliert Umgebungen?
Domain und E-Mail	Wer kann verlängern, DNS ändern und Zugriff wiederherstellen?
App-Stores und Analytics	Wer kann veröffentlichen, Daten sehen und übertragen?
Drittanbieterdienste	Wo werden Verträge, Rechnungen, Schlüssel und Verlängerungen verwaltet?

Diese Liste ergänzt den Leitfaden für Software-Eigentum nach dem Launch. Eine gute Einrichtung am Anfang ist einfacher als eine Rekonstruktion unter Druck.

Fragen Sie nach den Liefergegenständen

Lassen Sie sich Codebasis, Entwicklungsumgebung, Abhängigkeiten, Deployment, Tests und Dokumentation erklären. Klären Sie, ob individueller Code, Konfiguration, Design-Assets und Automatisierung enthalten sind, welche internen Komponenten ausgeschlossen sind und wie die Grenzen erkennbar bleiben.

Fragen Sie außerdem, wie bekannte Fehler, Sicherheitsupdates, Infrastrukturentscheidungen und Betriebsabläufe dokumentiert werden. Eine Übergabe sollte kein unlesbares Archiv sein, sondern einem künftigen Team genug Kontext für verantwortungsvollen Betrieb geben.

Kontinuität statt nur die Endübergabe prüfen

Zugriff muss während der gesamten Lieferung sichtbar sein. Gründer oder ein autorisierter interner Verantwortlicher sollten Repository, Projektboard, Staging und wichtige Entscheidungen sehen können. Regelmäßige Demos und kleine Releases machen Lücken sichtbar, solange die Beteiligten noch verfügbar sind.

Die Übergabe-Checkliste für nichttechnische MVP-Gründer hilft vor dem Launch. Nutzen Sie sie als Lieferreview, nicht als Formalität am letzten Tag.

Änderungen, Support und Trennung abdecken

Fragen Sie, was bei geänderten Prioritäten, einem ausscheidenden Anbieter, einem neuen Entwicklungspartner oder dem Austausch eines kritischen Dienstes geschieht. Unterscheiden Sie laufenden Support von Notfallzugriff und Übergangshilfe. Halten Sie Ansprechpartner, Reaktionszeiten und Verfahren zum Rotieren von Zugangsdaten fest.

Versprechen Sie keine zukünftige Beziehung, die nicht vereinbart ist. Klären Sie stattdessen aktuelle Verantwortungen und halten Sie die für den Betrieb benötigten Systeme aktuell dokumentiert.

Das Produkt als Unternehmens-Asset betrachten

Code allein ist kein vollständiges Produkt. Wert entsteht auch durch Datenmodelle, Abläufe, Kundenkommunikation, Deploymentwissen und Reaktionsfähigkeit bei Fehlern. Bitten Sie das Team in der Discovery, Abhängigkeiten verständlich zu erklären und bewusst einfache Teile der ersten Version zu benennen.

Das ist besonders bei KI-Diensten, No-Code-Tools und Managed-Plattformen wichtig. Das Team muss erklären können, wo Daten und Logik liegen, was exportierbar ist und welche Grenzen oder Kosten spätere Änderungen beeinflussen.

Eine schriftliche Prüfliste verwenden

Vor der Unterschrift sollten Vertrag und Lieferplan beantworten:

• Wer besitzt die Projektarbeit und welche Ausnahmen sind ausdrücklich genannt?
• Welche Unternehmenskonten enthalten Repository, Domain, Hosting und Produktdienste?
• Wer hat heute Admin-Zugriff und wie wird er sicher geändert?
• Welche Dokumentation, Konfiguration und Deployment-Information wird geliefert?
• Wie zeigt das Team, dass das Unternehmen das MVP nach der Übergabe betreiben kann?
• Was geschieht bei Vertragsende oder einer Übernahme durch ein neues Team?

Klare Antworten reduzieren Abhängigkeit, ohne dass ein Gründer jede technische Entscheidung beherrschen muss. Ein verantwortungsvolles MVP-Entwicklungsunternehmen sollte diese Fragen begrüßen.

Häufig gestellte Fragen

Sollte ein Startup den Quellcode seines MVP besitzen?

Gründer sollten schriftlich klären, wer Quellcode, Produkt-Assets, Konfiguration und verwandte Arbeit besitzt. Sie benötigen außerdem praktischen Zugriff auf Repositories und Konten, um das Produkt zu betreiben oder zu übertragen.

Was gehört zu einer Softwareübergabe?

Eine gute Übergabe umfasst Repository-Zugriff, Deployment- und Umgebungsinformationen, Kontoinhaberschaft, Dokumentation, Abhängigkeiten, Verfahren zur Zugangsdatenübertragung und bekannte Betriebsaufgaben. Der genaue Umfang muss vor der Lieferung feststehen.