Der häufigste Schmerz mit Individualsoftware kommt nicht während der Entwicklung — er kommt zwei bis vier Jahre später. Wenn ein Anbieter nicht mehr passt, ein anderer übernehmen soll oder eine eigene IT-Person die Lösung pflegen will, zeigt sich: der Quellcode liegt nur beim alten Dienstleister, die Cloud-Konten laufen auf dessen Namen, die Dokumentation ist dünn, und die Anbindung läuft über eine Plattform, die nur der Dienstleister bedienen kann. Das ist Lock-in — und er ist fast immer vermeidbar, wenn vor Vertragsschluss die richtigen Punkte geklärt sind.
Was Lock-in im Software-Kontext bedeutet
Lock-in ist die Situation, in der Sie ohne erheblichen Aufwand und Kosten den Dienstleister nicht wechseln können. Er entsteht typischerweise durch:
- Code-Eigentum beim Dienstleister statt beim Auftraggeber.
- Cloud-Konten auf Dienstleister-Namen.
- Spezielle Plattformen oder Frameworks, die nur der Dienstleister kennt.
- Fehlende Dokumentation.
- Datenformate, die nicht ohne weiteres exportierbar sind.
- Verträge, die Übergabe nicht regeln.
Lock-in kostet Geld — typischerweise zwischen 30 % und 100 % der ursprünglichen Entwicklungskosten, um ihn nachträglich aufzulösen.
Die zehn Punkte, die im Vertrag stehen sollten
1. Quellcode ist Eigentum des Auftraggebers Vollständige Übertragung der Rechte am Quellcode mit Abnahme jeder Iteration. Nicht „Nutzungsrecht”, sondern Eigentum.
2. Code wird in einem unabhängigen Repository abgelegt Auf einem Konto des Auftraggebers (GitHub, GitLab, Bitbucket, Azure DevOps). Der Auftraggeber hat Admin-Rechte und kann jederzeit klonen.
3. Lizenzen für eingesetzte Bibliotheken sind kompatibel Open-Source-Lizenzen mit klarer Verträglichkeit (MIT, Apache, BSD). Keine GPL-Bibliotheken in proprietärem Code ohne explizite Klärung. Liste der eingesetzten Pakete dokumentiert.
4. Cloud-Konten laufen auf den Namen des Auftraggebers AWS, Azure, Google Cloud, Hetzner, Vercel, Cloudflare — was auch immer genutzt wird, das Konto gehört dem Auftraggeber. Der Dienstleister bekommt einen Mitarbeiter-Zugang.
5. Datenexport ist jederzeit möglich Die Datenbank kann jederzeit als Standardformat (SQL-Dump, JSON, CSV) exportiert werden. Auch die historischen Daten.
6. Dokumentation ist Teil der Lieferung Architektur-Übersicht, Setup-Anleitung, Deployment-Beschreibung, wichtige Entscheidungen. So, dass ein anderer Entwickler binnen einer Woche produktiv sein kann.
7. Tests sind enthalten Automatisierte Tests sind Teil des Codes und dokumentieren die Funktionsweise. Eine Software ohne Tests ist eine Software, deren Funktionsweise nur im Kopf des Entwicklers existiert.
8. Standardtechnologien werden bevorzugt Wenn eine Aufgabe mit einem etablierten Framework (Django, Laravel, Spring, Next.js, Astro, .NET) lösbar ist, soll sie damit gelöst werden — nicht mit einer exotischen Plattform, die nur der Dienstleister beherrscht.
9. Übergabe ist im Vertrag Bei Vertragsende erfolgt eine vollständige Übergabe innerhalb von 30 Tagen, inklusive Wissenstransfer-Termin und schriftlicher Anleitung.
10. Pflege ist optional, nicht zwingend Sie sind nicht verpflichtet, die Pflege beim selben Anbieter zu beziehen. Pflegevertrag wird separat von Entwicklungsvertrag verhandelt und ist jederzeit kündbar.
Was Sie schon im Auswahlprozess fragen sollten
| Frage | Was Sie hören wollen |
|---|---|
| Wem gehört der Code am Ende? | Mir, mit allen Rechten. |
| Auf wessen Konten laufen Hosting und Dienste? | Auf meinem. |
| Welche Technologien verwendet ihr? | Etablierte, breit eingesetzte Frameworks. |
| Was ist Teil der Dokumentation? | Eine konkrete Liste, kein „bei Bedarf”. |
| Wie sieht ein Übergabe-Plan aus? | Schriftlich, mit Termin und Inhalt. |
| Was passiert mit Daten bei Vertragsende? | Vollständiger Export, dokumentiert. |
| Wer hat Admin-Zugang während der Entwicklung? | Mein Unternehmen, Dienstleister bekommt Sub-Account. |
Wenn auf eine dieser Fragen kein konkreter Antwort kommt, ist das ein Warnsignal — und keine Verhandlungssache, sondern eine Entscheidungsgrundlage.
Typische Lock-in-Konstrukte, vor denen Sie sich schützen sollten
- „Wir nutzen unsere eigene Plattform.” Sehr verbreitet, sehr riskant. Wenn die „eigene Plattform” des Dienstleisters die Grundlage ist, sind Sie für immer angewiesen.
- Cloud-Konto „aus Bequemlichkeit” beim Dienstleister. Klingt harmlos, ist es nicht. Im Streitfall sitzt der Anbieter auf Ihren Daten.
- „Wir geben den Code raus, wenn ihr aussteigt.” Soll im Vertrag stehen, nicht „dann sehen wir mal”.
- Lizenzkosten für jeden Endnutzer, die nur durch den Anbieter abgerechnet werden — auch wenn die Software „Ihre” ist.
- Domain auf Anbieter-Namen. Diese gehört Ihnen, immer. Punkt.
Was bei der Auswahl mehr wiegt als der Preis
- Erfahrung mit ähnlichen Projekten. Nicht nur Showcase-Liste, sondern Referenzgespräch.
- Methodik mit klaren Iterationen. Wer kein Konzept für Lieferung in 2-4-Wochen-Schritten hat, plant nicht.
- Klare Sprache. Wer Ihnen technische Sachverhalte verständlich erklärt, ist auch verständlich, wenn etwas nicht klappt.
- Größe und Stabilität des Anbieters. Sehr kleine Anbieter haben Bus-Faktor. Sehr große haben oft Kommunikationsdistanz. Mitte ist meist die richtige Wahl.
- Klare Aussagen zu allem oben Genannten — ohne Ausweichformulierungen.
Was es kostet, wenn Lock-in passiert
Beispiel: Eine Web-App, ursprünglich 45.000 € entwickelt. Nach drei Jahren möchte das Unternehmen den Anbieter wechseln, weil das Verhältnis nicht mehr passt.
- Reverse Engineering des Codes ohne Übergabe: 10.000 – 30.000 €.
- Datenmigration aus proprietären Strukturen: 5.000 – 15.000 €.
- Neuaufbau bei anderem Anbieter (weil Wiederverwendung schwierig ist): 25.000 – 50.000 €.
Gesamt: 40.000 – 95.000 € Mehrkosten, weil zu Beginn Lock-in nicht geklärt wurde.
FAQ
Können wir den Code wirklich weiterverkaufen oder anpassen lassen? Ja — wenn Sie ihn besitzen. Genau deshalb ist Code-Eigentum zentral.
Was, wenn der Anbieter Open Source verwendet? Üblich und gut. Open-Source-Bibliotheken sind keine Lizenzschwäche, sondern eine Stärke — sie sind dokumentiert, gepflegt und unabhängig vom Anbieter.
Wir haben eine bestehende Lösung — was tun, wenn Lock-in schon besteht? Sukzessive auflösen. Code-Übergabe verhandeln, Cloud-Konten umziehen, Dokumentation nachfordern. Mehrjähriger Prozess, oft 20–40 % der ursprünglichen Kosten. Besser jetzt anfangen als später.
Reicht ein Standardvertrag aus dem Internet? Selten. Software-Entwicklungsverträge brauchen klar formulierte Klauseln zu Eigentum, Übergabe und Lizenzen — vorlagenbasiert mit anwaltlicher Prüfung ist eine sinnvolle Mitte.
Wie wir das verstehen
Wir verstehen „ohne Lock-in” als Pflicht, nicht als Verkaufsargument. Code, Lizenzen, Konten und Dokumentation gehören Ihnen. Übergabe ist Teil des Vertrags, nicht Verhandlungssache. Wenn wir nicht mehr passen, müssen Sie ohne unsere Mitwirkung weitermachen können. Mehr dazu auf Software & Web-Apps. Wenn Sie noch grundsätzlich erwägen, welcher Software-Weg passt, hilft Standardsoftware oder Individualsoftware.