Bevor du einen Prototyp komplett neu bauen lässt, benenne die Anforderung, an der er scheitert. Bleiben Eingaben nach einem Verbindungsabbruch erhalten? Sind gespeicherte Vorgänge wieder auffindbar? Solche Fragen liefern einen konkreten Prüfauftrag.

Wie der Code entstanden ist, hilft bei dieser Entscheidung nur begrenzt. Maßgeblich ist, ob die vorhandene Anwendung den geplanten Einsatz bewältigt und welche Änderungen dafür fehlen.

Benenne den nächsten Einsatz

„Wir gehen live“ ist für eine Prüfung zu ungenau. Sollen eingeladene Testpersonen einen Datensatz anlegen und wiederfinden? Soll ein Team den Prototyp im Arbeitsalltag ausprobieren? Oder steht bereits ein öffentliches Angebot mit bezahlten Leistungen an? Der vorgesehene Einsatz verändert die Fragen, die vor dem Start geklärt werden müssen.

Wähle einen Nutzerweg, den du untersuchen lassen möchtest. Beschreibe auch, welche Daten dabei verwendet werden. In die erste Anfrage gehören weder Zugangsdaten noch Repository-Tokens.

Fiktives Beispiel: Im normalen Ablauf speichert die Anwendung einen Eintrag. Wird die Verbindung unterbrochen, bleibt der Button deaktiviert. Die Person weiß nicht, ob ihre Eingaben angekommen sind. Ein zweites Farbschema steht ebenfalls auf der Aufgabenliste.

Im Beispiel hat die Rückmeldung beim Speichern Vorrang: Die Person braucht Klarheit darüber, ob der Eintrag angekommen ist und wie sie weitermachen kann. Das zweite Farbschema lässt sich auf einen späteren Stand verschieben.

Die Prüfung muss sich auch mit ihrem eigenen Umfang festlegen: Wurde nur die Oberfläche betrachtet? Wurden Serverantworten nachvollzogen? Gab es Zugriff auf den betreffenden Code? Diese Unterschiede gehören in den Bericht.

Übergabefähig heißt: Jemand anderes findet sich zurecht

Für eine technische Übergabe helfen oft zunächst nüchterne Angaben. Wie startet man die Anwendung? Wo liegen die Daten? Wie wird eine Änderung bereitgestellt? Welche Dienste werden benötigt? Eine README hält solche Informationen am Projekt fest; GitHub beschreibt ihren Zweck als Orientierung im Repository.

Wenn die Übersicht fehlt, ergänze sie bei der Übergabe und lass eine zweite Person den beschriebenen Startweg ausprobieren.

Auffällige Ladezeiten brauchen wiederum Messbedingungen. Welches Gerät, welches Netz, welcher Zustand der Anwendung? Ein Ergebnis ohne diese Angaben ist schwer zu wiederholen. Web Vitals beschreibt die betrachteten Aspekte von Ladeverhalten, Reaktion und visueller Stabilität. Laborwerte sind dabei von Daten aus echter Nutzung zu unterscheiden.

Am Ende sollte ein begrenzter Review sagen, welche Probleme den benannten Start betreffen, welche Aufgaben später folgen und was nicht geprüft wurde. Er ersetzt keinen Pentest und keine rechtliche oder umfassende technische Produktionsfreigabe.

Der MVP-Launch-Check ist für einen Prototyp und einen zentralen Nutzerweg gedacht. Geht es vor allem um Aufbau und Wartbarkeit, passt eher der Technik- und Stack-Check. Für dasselbe Projekt grenzen wir mögliche Überschneidungen vor einer Beauftragung ab.