Der Termin steht, der Umfang nicht.
Der Pilot ist zugesagt, und im Team hält jeder etwas anderes für unverzichtbar. Die Liste wird länger statt kürzer.
Produkt- und UX-Prüfung vor dem Pilot
Ich sage dir, ob dein Nutzerweg einen Pilot trägt.
Ich prüfe Produktkern und Nutzung deines lauffähigen KI-Prototyps. Danach weißt du, was für einen begrenzten Pilot bleiben kann und was du vorher änderst.
Für Anbieter mit bestehenden Kunden, lauffähigem Prototyp und einem konkreten Pilot oder ersten Einsatz. Ich prüfe Produkt und Nutzung, nicht Code, Sicherheit, Datenschutz, Recht oder Betrieb.
Beispiel-Befund · 1 von 4 Vor dem Pilot
Geprüfter Nutzerweg · AktivierungVom Einstieg bis zum ersten Ergebnis
- 01EinstiegAufgabe verstanden?behalten
- 02KernschrittErgebnis eindeutig?ändern
- 03FehlerfallFehlerzustand fehltneu bauen
- 04ÜbergangNicht Teil des Pilotzielsstreichen
EmpfehlungKernweg begrenzen. Zwei Punkte vor dem Pilot ändern.
5 Arbeitstagetypischer Rahmen
1 Nutzerwegklar begrenzt
4 Entscheidungenbehalten, ändern, neu bauen oder streichen
Kurz vor dem Pilot
Der Prototyp läuft. Die Frage ist, ob er einen echten Kunden aushält.
In der Demo geht alles gut. Der erste echte Einsatz stellt andere Fragen.
Das Modell antwortet gut. Was passiert, wenn nicht?
Der gute Fall ist gebaut. Der leere, der falsche und der langsame Fall meistens nicht. Genau die sieht der erste Kunde.
Niemand kann sagen, wo es beim ersten Kunden bricht.
Ihr habt es hundertmal selbst benutzt. Deshalb sieht keiner mehr die Stelle, an der ein Fremder aussteigt.
Ein zweiter Anlauf kostet mehr als der erste.
Ein Pilot, der schiefgeht, ist nicht nur verlorene Zeit. Der Kunde erinnert sich daran, wenn du wiederkommst.
Prüfumfang
Vier Felder. Ein begrenzter Befund.
Im echten Einsatz zählen Einstieg, Fehlerfälle und ein klarer Pilotumfang. Jeder Befund verweist auf die sichtbare Stelle im geprüften Ablauf.
01
Produktkern
Welches Problem löst die erste Fassung? Ich trenne nötige Funktionen von Teilen, die den Start erschweren.
Klarer Umfang für Pilot oder erste Fassung02
Nutzerweg
Ich prüfe den zentralen Ablauf, seine Zustände, Fehlermeldungen und die Darstellung auf kleinen Bildschirmen.
Befunde entlang eines echten Ablaufs03
Start
Ich prüfe, ob Einstieg, Leistung, Bezahlweg und Rückmeldung zum geplanten Einsatz passen.
Begrenzter Plan für den nächsten Einsatz04
Offene Technikfragen
Ich markiere offene Punkte zu Anmeldung, Rechten, Daten, Zahlung und Betrieb. Code, Datenmodell und Sicherheit prüfe ich nicht.
Klarer Bedarf für eine getrennte PrüfungErgebnis
Am Ende steht eine Entscheidung und ein Bildschirm, den du anklicken kannst.
Ein Werkzeug über den Prototyp laufen zu lassen und das Ergebnis als PDF zu schicken, kannst du selbst. Von mir kommt eine Entscheidung und eine gebaute Stelle.
Die schlimmste Stelle, umgebaut
Kein Bild und kein Absatz darüber, sondern der Bildschirm selbst, zum Anklicken. Deine Entwicklung kann ihn übernehmen.
Klare Entscheidung
Zu jedem Befund steht, was bleiben kann, was du änderst, neu baust oder streichst. Kein Vielleicht.
Pilotumfang
Was der geplante Pilot wirklich braucht, und was bis danach warten kann. Meist ist die Liste kürzer als erwartet.
Reihenfolge
Die nächsten Schritte in einer Folge, die sich abarbeiten lässt. Offene technische Fragen markiere ich getrennt.
Auch ein Nein kann richtig sein: kleiner starten, Teile neu bauen, offene Fragen zuerst klären oder das Vorhaben beenden.
Prüfbare Produktarbeit
Vom Konzept bis zur laufenden App.
Das Beispiel belegt meine Arbeit an Produkt, Oberfläche, iOS-App und Backend. Es ist kein Beleg für die Prüfung fremden KI-Codes.
„Ist das gesund?“
Produktkonzept, App-Gestaltung, iOS-Entwicklung und Backend stammen von mir. Feste Regeln begrenzen die möglichen Urteile. Quellen kommen aus PubMed.
- Belegt
- Laufende App, Code und eigenes Backend
- Öffentlich
- App Store und Quellenansicht in der App
Ablauf
Fünf Arbeitstage für einen zentralen Nutzerweg.
Der Rahmen gilt für eine klar begrenzte Prüfung. Umfang und Festpreis stehen vor dem Start fest.
- Vor dem Start01
Ich kläre Eignung und Umfang.
Du schickst den Prototyp, den geplanten Einsatz und deine größte offene Frage. Ich prüfe, ob das Angebot passt.
- Tag 102
Wir legen Ziel und Nutzerweg fest.
Wir begrenzen die Prüfung auf eine Entscheidung und einen zentralen Ablauf.
- Tag 2–403
Ich prüfe und gewichte.
Ich teste den Ablauf, halte Befunde fest und ordne sie nach Wirkung und Aufwand.
- Tag 504
Du entscheidest.
Du bekommst Bericht, Reihenfolge und eine Empfehlung für den nächsten Schritt.
Das passt
Du stehst vor einem echten Einsatz.
- Dein Prototyp läuft.
- Du hast Kunden und einen geplanten Einsatz.
- Ein Pilot, Vertrag oder Start ist konkret geplant.
- Eine verantwortliche Person kann Entscheidungen treffen.
Grenze der Prüfung
Was sie nicht ersetzt.
- Ohne lauffähigen Prototyp und konkreten Einsatz passt das Angebot nicht.
- Code, Datenmodell und Sicherheit brauchen eine getrennte technische Prüfung.
- Datenschutz und Recht brauchen die jeweils zuständige Fachperson.
- Die Prüfung erteilt keine Freigabe für den Betrieb.
Ich prüfe Produktkern, Nutzerweg, Oberfläche und Pilotumfang. Offene technische Fragen markiere ich im Bericht.
Häufige Fragen
Was die Prüfung leistet, und was nicht.
Die Grenze ist Teil des Angebots. Offene Punkte klären wir vor dem Auftrag.
Weitere Frage stellenWelche Werkzeuge dürfen im Prototyp stecken?
Das Werkzeug ist zweitrangig. Der Prototyp kann etwa mit Lovable, Replit, Cursor oder Codex entstanden sein. Wichtig sind ein lauffähiger Stand, ein klarer Einsatz und Zugriff auf die nötigen Unterlagen.
Machst du den Prototyp während der Prüfung fertig?
Nein. Die Prüfung trennt Diagnose und Umsetzung. So bleibt sichtbar, was wirklich nötig ist. Änderungen können danach als eigener Auftrag folgen.
Ist das Produkt nach fünf Tagen startbereit?
Nicht automatisch. Die Prüfung zeigt, ob der zentrale Nutzerweg und der begrenzte Pilotumfang tragen. Sie ist keine Freigabe für Code, Sicherheit, Datenschutz, Recht oder Betrieb.
Prüfst du auch Code und Sicherheit?
Nein. Ich prüfe Produkt, Nutzerweg, Umfang und sichtbare offene Punkte zur Technik. Code, Datenmodell und Sicherheit brauchen einen eigenen Auftrag und einen passenden Entwickler.
Wann passt stattdessen die UX-Beratung?
Die UX-Beratung passt, wenn ein laufendes Produkt an einem belegten Nutzerweg stockt oder ein größerer Entwurf nötig ist. Diese Prüfung passt vor einem konkreten Pilot mit einem lauffähigen KI-Prototyp.
Was kostet die Prüfung?
Hier steht keine Zahl, und das hat einen Grund: ohne einen Blick auf Prototyp und Ziel wäre sie geraten. Danach bekommst du einen festen Umfang und einen Festpreis.
Erster Schritt
Du weißt vor dem Start, worauf du aufbauen kannst.
Schick mir Link, Ziel und geplanten Einsatz. Ich prüfe zuerst, ob das Angebot passt. Danach bekommst du Umfang, Termin und Festpreis. Erst dann entscheidest du.
Prototyp prüfen lassenDirekt an Stephan Lucka · keine allgemeine Verkaufsrunde