Agentur weg, Projekt halbfertig: weiterbauen oder neu aufsetzen?

Ein halbfertiges Projekt fühlt sich oft schlimmer an als eine alte Anwendung. Bei der alten weisst du wenigstens, was sie kann. Beim halbfertigen weisst du nur, was bestellt war, was bezahlt ist und dass es noch nicht läuft. Die Auslöser sind meist unspektakulär: Die Agentur hat ihr Team umgebaut, und dein Projekt hat keine Priorität mehr, der Freelancer hat eine Festanstellung angenommen, oder die Zusammenarbeit ist im Streit über Mehraufwand zu Ende gegangen.

Woran du merkst, dass dein Projekt liegen geblieben ist

• Auf dem Testserver sind Masken und Listen zu sehen, aber Bestellung, Rechnung oder Import enden in einer Fehlermeldung oder einem Platzhalter.
• Die letzte Änderung im Repository ist Wochen alt, falls du das Repository überhaupt sehen kannst.
• Auf Fragen nach dem Termin kommen nur noch vage Antworten.
• Niemand kann dir zeigen, wie die Anwendung auf den Live-Server kommt.
• Die Rechnungen laufen weiter, die Liste der offenen Punkte wird nicht kürzer.

Zuerst sichern, was da ist

Bevor jemand eine Zeile weiterschreibt, gehört alles, was zum Projekt existiert, an einen Ort, auf den deine Firma Zugriff hat:

1. Code mit Versionshistorie. Das vollständige Git-Repository, kein ZIP-Archiv. Die Historie zeigt, was wann entstanden ist und wo die Arbeit aufgehört hat.
2. Datenbank und Dateien vom Test- oder Entwicklungsserver, samt Testdaten.
3. Zugänge zu Server, Hosting, Domain und allen Drittdiensten, die schon angebunden sind, etwa Zahlungsanbieter oder Mailversand.
4. Projektunterlagen: Offerte, Pflichtenheft, Tickets, Designs, Abnahmeprotokolle und die Korrespondenz über Änderungen.

Antwortet der bisherige Anbieter gar nicht mehr, helfen dir die Sofortmassnahmen, wenn der Entwickler nicht erreichbar ist.

Wem die Rechte am halbfertigen Werk zustehen, lässt du juristisch klären.

«Sieht fertig aus» ist nicht «produktionsreif»

Der wichtigste Unterschied bei einem halbfertigen Projekt liegt zwischen dem, was in der Demo funktioniert, und dem, was im Betrieb trägt. Eine Maske, die Daten speichert, ist noch keine fertige Funktion, solange Eingabeprüfung, Rechteprüfung, Fehlerbehandlung und Tests fehlen. Eine Bestandsaufnahme zählt deshalb nicht die fertigen Seiten, sondern prüft diese Punkte:

Prüfpunkt	Frage	Warnzeichen
Vollständigkeit	Lässt sich das Projekt allein aus dem Repository aufsetzen?	Teile liegen nur auf dem Server oder auf dem Laptop des Entwicklers
Framework und PHP-Version	Bekommt die eingesetzte Version noch Sicherheitsupdates?	Laravel 11 zum Beispiel bekommt seit dem 12. März 2026 keine mehr
Abhängigkeiten	Liegt composer.lock im Repository, und was meldet composer audit?	Kein Lockfile, bekannte Lücken, aufgegebene Pakete
Datenmodell	Bildet es deine Abläufe ab, auch die Sonderfälle?	Tabellen, die nur für die Demo reichen
Rechte und Login	Prüft der Server bei jeder Aktion, wer sie ausführen darf?	Geprüft wird nur, welche Knöpfe sichtbar sind
Tests	Sichern automatisierte Tests die kritischen Abläufe ab?	Keine Tests oder Tests, die nichts Wesentliches prüfen
Betrieb	Gibt es Deployment, Backups und eine Konfiguration pro Umgebung?	Zugangsdaten im Code, Upload von Hand per FTP
Stand gegenüber Auftrag	Welche Punkte aus Offerte und Pflichtenheft sind fertig, angefangen oder offen?	Der Umfang wurde nur mündlich vereinbart

Die technischen Punkte beantwortet das Übernahme-Assessment mit einem Report innert fünf Arbeitstagen ab vollständigem Zugang. Legst du Offerte und Pflichtenheft dazu, ergibt sich daraus auch der Stand gegenüber dem Auftrag.

Weiterbauen, Teile neu schreiben oder neu aufsetzen?

Lage nach der Bestandsaufnahme	Sinnvoller Weg
Code vollständig, verbreitetes Framework mit Support, Datenmodell trägt	Weiterbauen: Lücken schliessen, Tests nachziehen, fertigstellen
Fundament trägt, einzelne Bereiche sind schwach, etwa Rechte oder Import	Weiterbauen und diese Bereiche gezielt neu schreiben
Datenmodell oder Architektur passt nicht zu deinen Abläufen	Neu aufsetzen, aber Anforderungen, Designs, Testdaten und brauchbare Teile mitnehmen
Code fehlt, ist unvollständig oder läuft nicht	Zuerst die Herausgabe klären, sonst Neustart auf Basis von Pflichtenheft und Demos

Das bereits ausgegebene Budget gehört nicht in diese Rechnung. Es ist weg, egal welchen Weg du wählst. Entscheidend ist, was jeder Weg ab heute bis zum stabilen Betrieb kostet und wie viel Risiko er trägt. Wie diese Abwägung bei bestehenden Anwendungen aussieht, beschreibt Modernisieren oder neu bauen.

Mit KI gebaut: Was eine Übernahme zusätzlich prüft

Immer öfter ist das halbfertige Projekt nicht bei einer Agentur entstanden, sondern grösstenteils mit KI-Werkzeugen, gebaut von einem Freelancer, von jemandem im Team oder von dir selbst. Manche nennen das «Vibe Coding». In der Demo läuft die Anwendung erstaunlich weit, und dann geht es nicht mehr weiter, weil niemand den Code wirklich kennt.

Dieser Abschnitt gilt für PHP-Anwendungen mit Laravel, Symfony oder ohne Framework. Läuft deine Anwendung auf einem JavaScript- oder Python-Stack wie Next.js oder Django, gelten ähnliche Prüfpunkte. Die Übernahme gehört dann aber zu jemandem, der genau diesen Stack betreut.

Was Studien zu KI-generiertem Code zeigen

• Sicherheit: Im «2026 GenAI Code Security Report» von Veracode, veröffentlicht am 28. Juli 2026, bestand der Code der getesteten Modelle die Sicherheitsprüfungen im Schnitt in 56 Prozent der Fälle, praktisch unverändert gegenüber dem Vorjahr. Veracode verkauft selbst Prüfwerkzeuge, gemessen wurde an vorgegebenen Programmieraufgaben, und PHP nennt die Mitteilung nicht.
• Falsche Sicherheit: In einer Studie von Forschenden der Stanford University (Perry et al., ACM CCS 2023) schrieben Teilnehmende mit KI-Assistent deutlich unsichereren Code als die Vergleichsgruppe und hielten ihn häufiger für sicher.
• Erfundene Pakete: Spracklen et al. (USENIX Security 2025) liessen 16 Modelle 576’000 Codebeispiele in Python und JavaScript erzeugen. Bei kommerziellen Modellen existierten im Schnitt mindestens 5,2 Prozent der vorgeschlagenen Pakete gar nicht, bei Open-Source-Modellen 21,7 Prozent. Wer einen solchen Namen registriert, kann Schadcode in Projekte bringen, die den Vorschlag ungeprüft übernehmen.

Typische Risiken in KI-gebauten PHP-Anwendungen

• Rechte nur in der Oberfläche: Der Knopf ist für normale Benutzer ausgeblendet, die Route dahinter aber offen. Fehlerhafte Zugriffskontrolle steht in den OWASP Top 10:2025 auf Platz 1.
• Mass Assignment: Ein Formular schreibt alle mitgeschickten Felder in die Datenbank. Die Laravel-Dokumentation beschreibt genau diesen Fall: Jemand schickt ein Feld is_admin mit und macht sich selbst zum Administrator.
• Zugangsdaten im Repository: API-Schlüssel im Code oder eine .env-Datei in der Versionsverwaltung, obwohl Laravel ausdrücklich davon abrät. Auch gelöschte Schlüssel bleiben in der Git-Historie lesbar.
• Debug-Modus auf dem Live-Server: Mit APP_DEBUG=true im Betrieb riskierst du laut Laravel-Dokumentation, sensible Konfigurationswerte offenzulegen.
• Erfundene oder veraltete Pakete: Paketnamen, die es nicht gibt, oder Code für Framework-Versionen, die keinen Support mehr haben.
• Viel Code, wenig Struktur: Dieselbe Logik an mehreren Stellen, keine Tests oder Tests, die am Wesentlichen vorbeiprüfen.

So prüft eine Übernahme KI-Code

1. Jedes Paket in composer.json existiert auf Packagist, stammt vom erwarteten Herausgeber und wird gepflegt, und composer audit meldet keine bekannten Lücken.
2. Jede Route und jede Aktion prüft serverseitig Anmeldung und Berechtigung, in Laravel etwa über Policies, in Symfony über Voters.
3. Die Anwendung validiert jede Eingabe, und Modelle nehmen nur ausdrücklich freigegebene Felder an.
4. Zugangsdaten liegen ausserhalb von Code und Historie. Jeder Schlüssel, der je im Repository lag, ist ausgetauscht.
5. Die Produktivkonfiguration stimmt: Debug-Modus aus, eigene Fehlerseiten, keine Passwörter oder Schlüssel in den Logs.
6. Die kritischen Abläufe haben Tests, die ein Mensch gelesen und verstanden hat.
7. Jemand kann jeden wichtigen Teil erklären. Code, den niemand selbst geschrieben hat, kennt auch niemand, und genau das ändert die Übernahme.

KI-Code ist kein Ausschlussgrund. Er ist so gut wie die Prüfung, die er durchlaufen hat. Wie der Einstieg aussieht, zeigt die Seite Webapplikation übernehmen. Damit das nächste Projekt nicht wieder an einer einzelnen Person hängen bleibt, hilft die Checkliste Neue Webapplikation in Auftrag geben, ohne abhängig zu werden.