Ihr KI-Prototyp überzeugt im Demo-Termin. Jetzt melden sich die ersten echten Kunden an.

Die Demo funktioniert: Ein Nutzer registriert sich, erstellt einen Auftrag und sieht ein sauberes Dashboard. Ein KI-Coding-Werkzeug hat den Weg von der Idee zu dieser Oberfläche erheblich verkürzt. Jetzt möchte ein Kunde seine Mitarbeiter einladen. Ein zweiter Kunde fragt nach Datenexport und einer verbindlichen Rechnung. Plötzlich geht es um Bedingungen, die im ersten Entwurf nicht vorkamen.

Für Gründer und mittelständische Unternehmen in Deutschland ist das ein guter Zeitpunkt für eine gezielte technische Übernahme. Der Prototyp hat bereits gezeigt, welche Abläufe verständlich sind. Das nächste Projekt muss klären, welche Teile echte Kunden und reale Geschäftsvorgänge zuverlässig tragen können. Eine pauschale Komplettsanierung ist dafür ebenso wenig hilfreich wie ein ungeprüfter Produktionsstart.

Prüfen Sie zunächst, was die Demo tatsächlich beweist

Eine funktionierende Oberfläche beweist, dass ein bestimmter Weg unter bestimmten Bedingungen durchlaufen werden kann. Sie beweist nicht automatisch, dass zwei Firmen sauber getrennt sind, eine Zahlung nur einmal verarbeitet wird oder ein verlorenes Administratorgerät ersetzt werden kann. Schreiben Sie die bislang getesteten Bedingungen ausdrücklich auf.

Unterscheiden Sie echte Integrationen von simulierten Daten. In frühen Prototypen ist es sinnvoll, Preise, Benachrichtigungen oder Dokumente zunächst zu vereinfachen. Vor dem Start müssen diese Stellen jedoch bekannt sein. Eine Schaltfläche mit dem Text „Rechnung gesendet“ darf nicht nur den lokalen Bildschirmzustand ändern, wenn der Kunde einen tatsächlichen Versand erwartet.

Lassen Sie die Bestandsaufnahme von einem konkreten Geschäftsablauf ausgehen. Zum Beispiel: Ein Firmenkunde legt einen Auftrag an, ein Mitarbeiter bearbeitet ihn, eine Rechnung wird erzeugt und später korrigiert. Dieser Ablauf verbindet Datenmodell, Berechtigungen und externe Dienste. Er zeigt technische Lücken verständlicher als eine lange Liste verwendeter Bibliotheken.

Eigentum und Zugänge sind Teil der Software

Prüfen Sie, in wessen Konto Repository, Domain, Hosting, Datenbank und externe Dienste liegen. Ihr Unternehmen benötigt einen geregelten Zugriff und einen Weg zur Wiederherstellung. Ein Deployment, das ausschließlich von einem persönlichen Konto abhängt, ist schwer zu übergeben, auch wenn der Quellcode vollständig vorhanden ist.

Dokumentieren Sie, welche Konfiguration beim Bauen und welche erst beim Start benötigt wird. Geheimnisse gehören nicht in öffentliche Dateien oder Beispielkonfigurationen mit echten Werten. Der übernehmende Partner sollte die Anwendung aus einem sauberen Checkout in einer getrennten Umgebung starten können. Diese Probe macht unsichtbare Abhängigkeiten schnell erkennbar.

Die GitHub-Dokumentation zur verantwortlichen Nutzung von Coding-Agenten betont die Prüfung und das Testen erzeugter Änderungen. Daraus folgt für die Beschaffung eine einfache Frage: Wer hat welche Teile geprüft, und wo liegen die Ergebnisse? Das verwendete Werkzeug ersetzt diese Verantwortung nicht.

Testen Sie fremde Nutzer und unerwartete Reihenfolgen

Berechtigungen werden im Prototyp oft aus Sicht eines einzigen Administrators entwickelt. Legen Sie mindestens zwei voneinander getrennte Kundenorganisationen und unterschiedliche Rollen an. Versuchen Sie dann, über direkte Links oder manipulierte Kennungen fremde Daten abzurufen. Die Prüfung muss auf dem Server greifen, nicht nur durch versteckte Schaltflächen.

Auch Reihenfolgen verdienen Aufmerksamkeit. Ein Webhook kann später eintreffen als erwartet. Ein Nutzer klickt zweimal. Ein Browser wird geschlossen, während der Server weiterarbeitet. Definieren Sie für solche Situationen stabile Vorgangskennungen und erkennbare Zustände. Ein Auftrag sollte nicht gleichzeitig bezahlt, unbekannt und erneut bestellbar erscheinen.

Bei Zahlungen oder anderen externen Aktionen ist ein Wiederholungsversuch besonders sorgfältig zu behandeln. Das System muss wissen, ob es dieselbe Aktion erneut bestätigt oder eine neue ausführt. Prüfen Sie die konkrete Anbieterintegration mit dessen Testumgebung und tatsächlichen Rückmeldungen. Eine zufällig erfolgreiche Demonstration reicht für diese Grenze nicht.

Machen Sie Sicherheitsanforderungen überprüfbar

Der OWASP Application Security Verification Standard bietet Anforderungen für die Prüfung von Webanwendungen und Diensten. Wählen Sie daraus die für Ihr Produkt passenden Prüfziele und dokumentieren Sie den Umfang. Eine unbestimmte Aussage wie „nach OWASP entwickelt“ sagt dem Auftraggeber sonst wenig darüber, was tatsächlich geprüft wurde.

Die technische Prüfung sollte verständliche Befunde liefern: betroffener Ablauf, mögliche Auswirkung, empfohlene Änderung und Nachweis nach der Behebung. Nicht jeder Befund verhindert denselben Startumfang. Ein intern genutzter Pilot und ein öffentliches Kundenportal haben unterschiedliche Voraussetzungen. Diese Abwägung sollte explizit bleiben.

Datenschutz und Datenaufbewahrung benötigen ebenfalls Produktentscheidungen. Welche Angaben sind für den Ablauf notwendig? Wer darf sie exportieren oder löschen? Was geschieht mit Sicherungskopien? Die Entwicklung kann diese Regeln umsetzen, aber sie sollte sie nicht stillschweigend aus einer generierten Vorlage ableiten.

Betreiben heißt auch wiederherstellen können

Ein erfolgreiches Deployment ist nur ein Teil des Starts. Benennen Sie, wer auf Fehlermeldungen reagiert, wie Änderungen veröffentlicht werden und wo ein dokumentierter Rückweg liegt. Prüfen Sie eine Wiederherstellung in einer getrennten Umgebung. Eine vorhandene Sicherungsdatei ist noch kein Nachweis, dass Daten und Anwendung gemeinsam wieder funktionieren.

Beobachten Sie fachliche Fehler neben technischen Ausfällen. Der Server kann erreichbar sein, während keine Bestätigungsmails ankommen oder Aufträge in einer Warteschlange stehen. Ein kleines Betriebsdashboard sollte die für Ihr Geschäftsmodell entscheidenden Übergänge sichtbar machen. Dazu gehören klare Zuständigkeiten für offene Vorgänge.

Kaufen Sie die nächste belastbare Stufe

Ein guter Übernahmeauftrag trennt Untersuchung, notwendige Korrekturen und spätere Erweiterungen. Für den ersten echten Nutzungskreis sollten folgende Ergebnisse vorliegen:

• Ein reproduzierbarer Start aus dem übergebenen Repository.
• Nachgewiesene Trennung der vorgesehenen Kunden und Rollen.
• Ein geprüfter Umgang mit doppelten und unterbrochenen Geschäftsvorgängen.
• Ein nachvollziehbarer Datenexport und ein getesteter Wiederherstellungsweg.
• Klare Betriebszuständigkeiten und eine dokumentierte Veröffentlichung.
• Eine Liste bewusst noch nicht unterstützter Abläufe.

Vergleichen Sie Angebote anhand dieser Ergebnisse. Eine niedrige Zahl an Entwicklungstagen hilft wenig, wenn wesentliche Entscheidungen als spätere Zusatzleistung auftauchen. Ebenso sollte ein Partner erklären können, welche vorhandenen Teile erhalten bleiben und warum. Der Prototyp enthält bereits Produktwissen, das bei einem ungezielten Neustart verloren gehen kann.

Unsere Beiträge zur Übernahmeprobe beim Dienstleisterwechsel und zu vergleichbaren Softwareangeboten helfen bei der Auswahl. Ausgewählte Arbeiten finden Sie zusätzlich im Portfolio von Anis Khalef. Innovation T begleitet solche Vorhaben über seine Softwareleistungen. Zeigen Sie uns Ihren Prototyp und den ersten geplanten Kundenvorgang, um den nächsten Schritt konkret abzugrenzen.

Häufige Fragen

Muss ein mit KI erstellter Prototyp komplett neu gebaut werden?

Nicht automatisch. Eine technische Bestandsaufnahme sollte brauchbare Teile, konkrete Risiken und fehlende Betriebsfunktionen unterscheiden. Erst danach lässt sich entscheiden, was übernommen, verbessert oder ersetzt werden sollte.

Reicht ein bestandener Sicherheitsscan für den Produktionsstart?

Nein. Ein Scan ist ein Baustein. Fachliche Abläufe, Zugriffsrechte, Wiederherstellung, externe Integrationen und das Verhalten bei Fehlern benötigen zusätzlich passende Prüfungen.

Was sollte der erste Auftrag an einen Entwicklungspartner liefern?

Eine nachvollziehbare Bestandsaufnahme, priorisierte Befunde und einen überprüfbaren Plan für den ersten realen Nutzungskreis. Dazu gehören klare Entscheidungen über Daten, Zugänge, Betrieb und die Verantwortung nach dem Start.