Neue Webapplikation in Auftrag geben, ohne wieder abhängig zu werden

Abhängigkeit entsteht selten aus böser Absicht. Sie entsteht, weil es am Anfang bequemer ist: Die Agentur registriert die Domain schnell selbst, eröffnet das Hosting auf ihr Konto, legt das Repository in ihre Organisation und die Zugangsdaten in ihren Tresor. Solange die Zusammenarbeit läuft, fällt das niemandem auf. Erst beim Wechsel zeigt sich, was deiner Firma tatsächlich gehört und was nur im Kopf einer einzelnen Person steckt.

Woran du merkst, dass du gerade wieder in eine Abhängigkeit läufst

• Die Offerte erwähnt Code, Hosting und Domain nicht oder nur als «inklusive».
• Du bekommst Demos zu sehen, aber keinen Zugang zum Repository.
• Die Anwendung soll auf einem hauseigenen Framework oder CMS der Agentur entstehen.
• Zugangsdaten kommen per E-Mail oder gar nicht.
• Die Dokumentation ist für «nach dem Go-live» geplant.

Checkliste: 11 Punkte für Vertrag und Projekt

Was deiner Firma gehört

1. Code im eigenen Repository. Das Repository liegt ab dem ersten Tag in einer GitHub- oder GitLab-Organisation deiner Firma, die Agentur arbeitet darin mit. Die Owner-Rolle mit vollem Verwaltungszugriff haben Personen aus deiner Firma, GitHub empfiehlt mindestens zwei. Externe bekommen Zugriff auf die Repositories, die sie brauchen.
2. Domain auf deine Firma. Deine Firma ist Halterin der Domain, und das Konto beim Registrar läuft auf eine Mailadresse der Firma, nicht auf eine Person.
3. Hosting und Drittdienste auf deine Firma. Hosting, Mailversand, Zahlungsanbieter, Karten- und API-Schlüssel, Monitoring: Vertrag und Rechnung laufen auf deine Firma, die Agentur bekommt Zugang.
4. Zugänge im eigenen Passwort-Tresor. Der Tresor gehört deiner Firma, die Agentur bekommt Zugriff auf einen geteilten Bereich. Kein Passwort per E-Mail und keines im Code. Laravel etwa rät ausdrücklich davon ab, die .env-Datei mit den Zugangsdaten in die Versionsverwaltung zu legen.
5. Lizenzen auf deine Firma. Kostenpflichtige Erweiterungen, Themes, Schriften und Dienste sind auf deine Firma registriert, sonst enden die Updates mit der Zusammenarbeit.

Was die Technik mitbringen muss

6. Standard-Framework statt Eigenbau. Laravel, Symfony oder TYPO3 statt eines hauseigenen Frameworks. Verbreitete Frameworks haben eine öffentliche Dokumentation, veröffentlichte Supportzeiträume und viele Fachleute, die sie kennen. Laravel gibt jeder Version 18 Monate Fehlerbehebungen und zwei Jahre Sicherheitsupdates, die Symfony-LTS-Version 7.4 bekommt Fehlerbehebungen bis November 2028 und Sicherheitsupdates bis November 2029.
7. Abhängigkeiten über Composer. Alle Pakete sind in composer.json erfasst, und composer.lock liegt im Repository, wie es die Composer-Dokumentation empfiehlt. So arbeiten alle mit denselben Versionen, auch eine spätere Nachfolge.
8. Automatisierte Tests für die kritischen Abläufe. Login, Bestellung, Import oder was sonst für dein Geschäft zählt, läuft bei jeder Änderung automatisch durch. Ohne Tests traut sich später niemand an den Code.
9. Reproduzierbares Deployment. Ein dokumentierter, automatisierter Weg vom Repository auf den Server, mit eigener Konfiguration pro Umgebung. Niemand kopiert Dateien von Hand.
10. Backups mit getesteter Wiederherstellung. Backups liegen ausserhalb des Servers, und die Wiederherstellung ist mindestens einmal geprobt.

Was an Wissen übergeben wird

11. Dokumentation als Teil der Abnahme. README, Betriebshandbuch mit Deployment, Backups, Cronjobs und Notfallablauf, eine Schnittstellenübersicht und ein Entscheidungsprotokoll, alles im Repository. Ohne Doku ist das Projekt nicht abgenommen. Welche Dokumente es braucht, zeigt die Tabelle in PHP-Anwendung ohne Dokumentation übernehmen.

Was der Vertrag regeln sollte

Eine fertige Ausstiegsklausel findest du hier bewusst nicht. Vertragstext gehört in juristische Hände. Diese Punkte gibst du deiner Juristin oder deinem Juristen als Auftrag mit:

• Rechte am Code: Darf deine Firma den Code nutzen, ändern und von Dritten weiterentwickeln lassen, auch Bausteine, die der Anbieter in mehreren Projekten einsetzt?
• Herausgabe: Wann und in welcher Form bekommst du Code, Datenbank, Dokumentation und Zugänge, auch während das Projekt noch läuft?
• Mitwirkung beim Wechsel: Wie lange und zu welchen Konditionen hilft der bisherige Anbieter bei einer Übergabe?
• Getrennte Kündbarkeit: Lassen sich Entwicklung, Wartung und Hosting einzeln kündigen, und mit welchen Fristen?
• Fremdkomponenten: Welche Open-Source- und Kaufkomponenten stecken drin, und unter welchen Lizenzen?
• Abnahmekriterien: Die Dokumentation steht als Bedingung für die Abnahme im Vertrag.

Dieselben Regeln gelten für Unique-P

Niemand soll wieder von einer einzelnen Person abhängen, auch nicht von mir. Ich arbeite allein, deshalb gilt die Liste oben für jedes Projekt, das ich baue: Code und Dokumentation liegen auf GitHub, auf Wunsch in deiner eigenen GitHub-Organisation. Die Zugänge liegen in einem gemeinsamen Passwort-Tresor, auf den du jederzeit Zugriff hast, und Hosting-Konto, Domain und Lizenzen gehören deiner Firma. So kann jederzeit eine andere Fachperson übernehmen. Wie eine Neuentwicklung abläuft, zeigt die Seite Webapplikation entwickeln.

Die Gegenprobe

Ob die Vorsorge funktioniert, zeigt sich erst, wenn jemand übernehmen muss. Die Checkliste für die Übernahme einer Webapplikation ist deshalb die Gegenprobe: Jeder Punkt, den du dort schon beim Projektstart abhaken kannst, ist eine Abhängigkeit weniger. Steckt dein aktuelles Projekt bereits fest, hilft Halbfertiges Projekt übernehmen. Löst die neue Anwendung ein Altsystem ab, gehören auch die Daten in den Plan: Daten aus dem Altsystem mitnehmen.