Der Code war der einfache Teil daran, Prova zu shippen

In dem Moment fühlte sich Prova für mich real an, als das Produkt aufhörte, mir zu erlauben, mich selbst zu belügen.

Eine Homepage kann sehr lange aspirational bleiben.

Ein Produkt, das live ist, kann das nicht.

Sobald Menschen sich anmelden, ihre E-Mail bestätigen, an der falschen Stelle landen, Billing-State berühren, Arbeit einreichen und erwarten, dass das System sich merkt, was passiert ist, verschiebt sich der Bottleneck.

Das Produkt beginnt, echte Versprechen zu machen. Und die unsichtbare Arbeit wird plötzlich sehr sichtbar.

Update am 16. April 2026: Seit ich die erste Version dieses Posts entworfen habe, hat sich Prova bereits hin zu einem klareren Operator/Builder-Split verschoben. Ich habe die Kernthese intakt gelassen und die produktspezifischen Details unten aktualisiert, damit der Post mit dem übereinstimmt, was jetzt live ist.

Wenn ihr die drei Posts gesehen habt, die ich im März und Anfang April über meinen Wechsel von Claude Max zu Codex geschrieben habe: Dieses Experiment läuft noch. Ich habe bereits versprochen, am May 2, 2026 einen richtigen Follow-up zu veröffentlichen. Dieser Post ist nicht dieser Post.

Der schwierige Teil war, jedenfalls in diesem Push für mich, nicht, ein LLM Code generieren zu lassen. Es war alles rund um den Code.

Wenn ihr gerade mit AI baut, vor allem etwas, das echte Nutzer, echtes Geld oder echten Produkt-State berührt, dann ist das wahrscheinlich genau der Teil, vor dem euch kaum jemand warnt.

Der Name war der einfache Teil

Ich muss zugeben: Prova zu benennen war die einfache Entscheidung. Prova heißt so etwas wie Beweis oder Test, und das passt genau zum eigentlichen Job des Produkts: Menschen dazu zu bringen, ihre Arbeit zu beweisen, statt ihnen zu schmeicheln und ihnen das Gefühl zu geben, sie seien schon Builder.

Der schwerere Teil begann direkt danach. In dem Moment, in dem Prova nicht mehr nur ein Name und eine Landingpage war, verlangte es plötzlich all die unglamourösen Dinge, die echte Produkte eben verlangen:

• assessment logic
• onboarding state
• authored progression
• review visibility
• billing flows
• auth hardening
• content publishing
• release gates

Das hat verändert, wie ich über AI-Tools und über Product Building nachdenke.

Wozu Prova wirklich werden musste

Prova ist jetzt ein opinionierteres Produkt, als es war, als ich diesen Post zu entwerfen begann. Die Oberfläche hat sich in zwei klarere entry paths aufgeteilt: einen Operator path für Menschen, die Workflows neu entwerfen, und einen Builder path für Menschen, die eine erste nützliche Scheibe ausliefern wollen. Auf der Builder-Seite bedeutet das inzwischen einen Build Reality Check, ein Build Brief, einen Build Plan, eine execution lane, solange der Build in Bewegung ist, und ein launch gate, bevor man es einem echten Nutzer zeigt.

Unter dieser saubereren Oberfläche ist die härtere Systemarbeit derselbe Punkt, den ich schon gemacht habe, als ich diesen Post entworfen habe. Es geht immer noch um Assessment und Onboarding, ein sprint-first Produkt statt eines chat-first, reviewgetriebene Progression, dauerhaften Produkt-State und eine Mentor-Schicht, die sich eher wie Office Hours rund um den aktuellen Sprint anfühlt als wie eine generische AI-Chatbox.

Nur zur Klarstellung: Ich behaupte nicht, dass Prova "fertig" ist. Ich wünschte, ich könnte das sagen und dann einfach weitergehen, aber das wäre etwas zu bequem und wahrscheinlich auch nicht wahr. Die richtige Einordnung heute ist weiterhin controlled launch: Der Billing Portal und die Recovery Flows sind live, aber die offene Arbeit hat sich von grundlegender Produktinfrastruktur hin dazu verschoben, den Builder path, die execution lane und das launch gate unter echter Nutzung ehrlicher zu machen. Ich glaube sogar, dass die Lektion dadurch nützlicher wird, nicht weniger. So sieht Produktarbeit in der echten Welt aus. Nicht fertig. Nicht fake. Nur echt genug, dass der nächste Fehler etwas kostet.

Die Arbeit, die ich nicht einfach generieren konnte

Die einfachste Version eines AI-Produkts ist die Demo-Version.

Die bekommt man schnell dazu, lebendig auszusehen:

• eine Homepage
• eine Chatbox
• ein paar glatte Screenshots
• ein überzeugender Produktsatz

Das ist nützlich für einen Launch-Teaser.

Es ist nicht besonders nützlich, wenn man verstehen will, wo die eigentliche Arbeit liegt.

Für mich tauchte diese Arbeit an sechs Stellen auf.

1. Das Sprint-System musste aufhören zu bluffen

Ich wollte nicht, dass Prova so ein Produkt wird, das auf der Landingpage strukturiert aussieht und innen sofort generisch wird.

Feste, authored Sprints waren so lange hilfreich, bis sie es nicht mehr waren.

Das eigentliche Problem kam in dem Moment, in dem ein Learner einen Sprint bestand, die nächste reale Lücke aber nicht dem nächsten authored Sprint im Katalog entsprach.

Die faule Antwort wäre gewesen:

"Lass das Modell einfach den nächsten Sprint erfinden: Titel, Rubric, Review Criteria, alles."

Dem habe ich nicht vertraut.

Also musste das System strenger werden.

Jetzt kann der Reviewer immer noch den kanonischen nächsten Sprint empfehlen, wenn der authored Pfad stimmt. Es kann einen adaptive detour zuweisen, also einen temporären Sprint, der einem Learner hilft, ein Fundamentproblem zu beheben, bevor er auf den Hauptpfad zurückkehrt. Und wenn die nächste echte Lücke außerhalb des authored Katalogs liegt, kann es stattdessen einen composed sprint anfordern.

In einem Blogpost klingt das klein.

In einem Produkt ist es nicht klein.

Denn ein composed sprint ist nicht einfach nur "dynamischer Text".

Er muss einen Platzhalter-Sprint anlegen, die Zuweisung persistieren, den Rückweg zur kanonischen Roadmap erhalten, das Sprint-Paket füllen und danach vom restlichen System wie echter Produkt-State behandelt werden können.

Die Constraint, die das vertrauenswürdig gemacht hat, war ziemlich simpel:

Das Modell darf den Standard nicht selbst erfinden.

Der composed sprint füllt nur das Paket: title, summary, context, assignment, example.

Submission schema und review rubric kommen weiterhin aus einem authored Template-Sprint.

Das war eine der größten Lektionen in diesem gesamten Build.

Wenn etwas Dynamisches vertrauenswürdig bleiben soll, dann halte den Vertrag fest und lass das Modell innerhalb dieses Vertrags arbeiten.

Genau hier hat Codex mir auch besonders geholfen. Nicht auf eine flashy Art im Sinne von "schau mal, was es generiert hat". Sondern auf eine viel nützlichere Art: Migrations, Router-Logik, Platzhalter-Lifecycle, Request-State, Integration-Tests und all die langweilige Vertragsarbeit, die ein dynamisches Produkt weniger fake macht.

Und ich muss zugeben: Die faulere Version war durchaus kurz verlockend. Lass das Modell clever sein. Lass das System magisch wirken. Räum später auf. Das klingt großartig, bis man sich vorstellt, einem zahlenden Nutzer eine schlechte Sprint-Zuweisung erklären zu müssen.

2. Retrieval musste curricular werden, nicht nur semantisch

In dem Moment, in dem das System Sprints komponieren durfte, war Retrieval-Qualität kein Backend-Detail mehr.

Sie wurde Curriculum-Qualität.

Wenn das Produkt einen Sprint zu Tooling, Measurement oder Competitive Intelligence komponieren sollte, konnte es nicht einfach "halbwegs verwandte" Chunks aus der Knowledge Base ziehen und hoffen, dass das Paket schon irgendwie stimmig wirken würde.

Die Knowledge Base selbst musste schlauer werden.

Wir haben sie aus dem echten Corpus neu aufgebaut: Blogposts, Course Modules, Transcripts, Companions, Templates und Deep-Dive-Ressourcen.

Dann haben wir diese Quellen je nach Typ unterschiedlich gechunked.

Narrative Blogposts konnten größer bleiben.

Instructional Modules brauchten heading-first Chunks.

Templates und Reference Assets brauchten strukturierteres Chunking, damit Tabellen, Checklists, Slide References und Quick-Reference-Abschnitte nicht in generische Absätze plattgedrückt wurden.

Dann kam Tagging ins Spiel.

Nicht nur "worum geht es hier?" sondern auch:

• was für eine Art Chunk das ist
• welche topic tags passen
• für welches Publikum das Material gedacht ist
• auf welchem difficulty level es liegt

Das hat Retrieval von "nearest vector wins" zu etwas verändert, das eher curricular matching ähnelte.

Das Produkt konnte damit Fragen stellen wie:

"Gib mir grounded Material für dieses Thema, für dieses Publikum, auf diesem Niveau."

Das ist ein viel ernsteres System, als einfach RAG an eine Demo dranzuschrauben.

3. Evals mussten die Pipeline testen, nicht nur das Modell

Ich wollte keinen Sieg ausrufen, nur weil ein einzelner composed sprint im UI ordentlich aussah. Also musste das Eval-System mit dem Produkt mitwachsen.

Zuerst gab es die Sprint-Review-Eval-Harness. Dann kam für Composition ein Retrieval Gate dazu, im Grunde ein pass/fail check, ob tagged Retrieval das grounded Material gegenüber der ungetaggten Baseline tatsächlich verbessert. Und dann kam ein komplettes End-to-End-Harness dazu: sprint packet komponieren, schema-valide synthetische submissions erzeugen, den echten reviewer gegen diese submissions laufen lassen und die Ergebnisse nach grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality und Vergleichbarkeit mit authored work beurteilen.

Es ging darum zu verhindern, dass "personalisierte Progression" einfach in fake personalization umkippt. Wenn das System sagen will: "Dieser nächste Sprint ist wirklich für dich", dann braucht es mehr als ein Paket, das ordentlich aussieht. Es braucht Belege dafür:

• blieb das Paket grounded
• veränderte die Track-Framing die eigentliche Arbeit wirklich
• fühlte sich level 2 gegenüber level 5 tatsächlich anders an
• traf der reviewer weiterhin die richtige pass/revise Entscheidung
• gehörte sich der composed sprint weiterhin in das Curriculum hinein, statt daneben zu schweben

Diese Schleife hat echte Probleme sichtbar gemacht. Schwache revise submissions, die immer noch zu stark waren. Audience-Framing, das über verschiedene Tracks hinweg zusammenfiel. Measurement-Pakete, die gut klangen, aber für verschiedene Learner nicht wirklich unterschiedliche Vertrauensfragen beantworteten.

Einer der demütigenderen Momente für mich war zu merken, wie oft etwas im UI "ziemlich gut" aussehen konnte und trotzdem sofort auseinanderfiel, sobald ich eine härtere Frage stellte. Ein Paket konnte sauber klingen und trotzdem zu generisch sein. Ein revise case konnte plausibel wirken und dennoch zu leicht sein. Das war ziemlich gut für mein Ego, glaube ich.

Das System wurde nicht besser, weil ich einmal einen guten Prompt hatte. Es wurde besser, weil das Produkt vor mir in einer Eval-Harness scheitern konnte, bevor es vor Nutzern scheiterte. Das war kein einzelnes Wunder. Das war eine kontrollierte Schleife.

4. Die Stellen, an denen Vertrauen entsteht, mussten echt sein

Auch daran unterscheiden sich echte Produkte sehr schnell von Demos.

Niemanden interessiert, wie elegant deine AI-Schicht ist, wenn:

• email confirmation kaputt ist
• Google sign-in wackelt
• der Nutzer in einer auth loop hängen bleibt
• abuse controls fehlen
• account hardening wie ein Nachgedanke wirkt

Bei Prova gehörten zu dieser Vertrauensebene am Ende:

• email confirmation, die Nutzer wieder in den richtigen Produktfluss zurückbringt
• Google SSO
• optionale app-basierte Zwei-Faktor-Authentifizierung (TOTP MFA)
• Turnstile-Schutz auf auth und assessment

Das ist genau die Art Arbeit, mit der kaum jemand angibt, weil sie operativ und langweilig klingt.

Ich glaube, das ist ein Fehler.

Gerade im Langweiligen und Operativen verdienen Produkte Vertrauen oder verlieren es leise.

5. Billing musste testbar sein, nicht nur vorstellbar

Ich werde zunehmend skeptisch bei Produktleuten, die über Monetarisierung so reden, als wäre sie nur einen Stripe-Screenshot davon entfernt, gelöst zu sein.

Billing wird sehr schnell real.

Es geht nicht nur um:

"Kann technisch irgendjemand bezahlen?"

Sondern um:

• was im trial state passiert
• was passiert, wenn webhook state zu spät ankommt
• wie man sicher testet, ohne Theater auf der eigenen Umsatzfläche zu spielen
• wie man den gesamten Flow verifiziert, ohne einmalige Ausnahmen zu erfinden, die das System später unzuverlässiger machen

Prova hat inzwischen einen echten Subscription-Flow plus einen internen QA-Checkout-Pfad für sicherere Billing-Verifikation. Das klingt vielleicht klein. Ist es nicht. Je ernster ein Produkt wird, desto mehr braucht man Möglichkeiten, kommerzielle Logik zu testen, ohne sich selbst über den Verifikationsstand anzulügen.

6. Operations mussten Teil des Produkts werden

Einer der Punkte, an denen Prova sich für mich real anfühlte, war der Moment, in dem ich es als eigenes operatives System behandeln musste und nicht als Feature, das ich irgendwo in meine bestehende Site schiebe. Separates production system, separates Supabase project, separates Vercel project, separate auth configuration, separates billing setup, separate release gates.

Dieser Satz ist nicht sexy. Er ist auch wahrscheinlich der Satz, der am meisten zählt.

Denn Produkte brechen nicht nur auf UI-Ebene. Sie brechen dort, wo Systeme sich berühren, wo Annahmen auslaufen, wo Environments driften, wo jemand sagt: "Das fixen wir nach dem Launch", und die Post-Launch-Version dann nie wirklich kommt.

Je mehr ich an Prova gearbeitet habe, desto mehr Respekt bekam ich vor langweiligen operativen Sätzen.

Wenn ihr einen schnellen Drucktest für euer eigenes AI-Produkt wollt, fragt:

• welcher Standard fest bleibt, wenn das Modell dynamisch wird
• welches Retrieval den Output grounded hält
• welches Eval fake personalization abfängt, bevor es ein Nutzer tut
• welche Auth-, Billing- oder State-Edge euch morgen peinlich wäre

Wenn diese Antworten schwammig sind, ist das Produkt wahrscheinlich noch mehr Demo als System.

Der Beweis, der wirklich zählt

Ich möchte über Productization nicht nur abstrakt reden, weil es sonst philosophischer klingt, als es eigentlich ist.

Der wichtigste Beweis ist nicht: "Wie viele Migrations habe ich geschrieben?"

Es ist: Was funktioniert jetzt für einen echten Nutzer?

In dieser Soft-Launch-Phase kann das Produkt jetzt glaubwürdig sagen:

• email signup, confirmation und password recovery funktionieren
• Google SSO funktioniert
• optionale TOTP MFA funktioniert
• downloadable resources und signed downloads funktionieren
• sprint submission und AI review funktionieren in production
• Stripe checkout handoff und billing portal access funktionieren

Das ist die buyer-facing Schicht von Beweis.

Darunter gibt es auch Systembeweise aus Repo und Rollout:

• 4,390 Production-Knowledge-Base-Rows, veröffentlicht und für Composition Retrieval getaggt
• ein tagged retrieval gate, das die untagged baseline schlägt
• eine vollständige 18-case composition eval suite, die ihr Gate besteht
• ein sichererer interner QA checkout path für Billing-Verifikation

Was ich noch nicht habe, ist breiter externer Beweis von einer sinnvollen Menge an Nutzern, die sagen: "Das hat meine Ergebnisse verändert." Dafür ist es noch zu früh, und ich möchte das nicht fake machen.

Ich nenne sie, weil es sehr leicht ist zu unterschätzen, was "eine Idee in ein Produkt verwandeln" tatsächlich bedeutet, wenn man nur in Launch-Sprache darüber spricht.

Der wichtige Teil sind nicht die Zahlen an sich.

Sondern wofür sie stehen:

• das Sprint-System hat aufgehört, nur Dekoration zu sein
• Retrieval hat aufgehört, unscharf zu sein
• Evaluation hat aufgehört, performativ zu sein
• Produkt-State ist belastbar genug geworden, um sich darauf zu verlassen

Unsichtbare Arbeit bleibt Arbeit.

Und meistens ist es die härtere Arbeit.

Was das in meinem Kopf verändert hat

Ich glaube immer noch, dass AI-Tools wichtig sind. Natürlich sind sie das. Codex war in diesem Push hilfreich, weil es kompetent, vorsichtig und methodisch wirkte. Es war gut darin, mir durch Engineering-Arbeit zu helfen, ohne viel emotionale Show daraus zu machen. Claude fühlt sich für mich immer noch besser an, sobald Arbeit geschmackslastiger und kreativer wird. Das volle 30-Tage-Codex-Urteil kommt am May 2, 2026, und dieser Post wird der richtige Ort für die Kosten-Zeitleiste, die Limits-Story und das, was sich in meinem täglichen Arbeitsmodell verändert hat.

Aber Prova hat mich zu einer wichtigeren Schlussfolgerung geschoben als jeder Tool-Vergleich:

AI kann Implementation beschleunigen, aber sie nimmt einem nicht die Urteilsarbeit bei Produktgrenzen, Sequencing, Glaubwürdigkeit und operativer Wahrheit ab. Diese Urteilsarbeit bleibt die Arbeit.

Eine Landingpage ist kein Produkt. Ein benanntes Konzept ist kein Produkt. Eine generierte Component ist ganz sicher kein Produkt.

Was etwas für mich wie ein Produkt wirken lässt, ist die unsichtbare Architektur rund um die sichtbare Erfahrung. In dem Moment, in dem echte Nutzer eintreten, bezahlen, vorankommen, blockiert werden, sich erholen, Arbeit einreichen und dem State vertrauen können, den sie sehen, spielt man nicht mehr mit einer Demo. Man macht Versprechen.

Versprechen sind der Punkt, an dem Product Building ernst wird. Diesen Teil respektiere ich heute mehr, und ich glaube, das ist der Teil, über den viel mehr Builder sprechen sollten.

Häufige Fragen

Was ist Prova?

Prova ist jetzt ein strukturiertes Coaching-Produkt für Marketer und Werbeprofis, die einen ernsthafteren Weg in die AI-Arbeit suchen. Aktuell gibt es zwei klarere entry paths. Der Operator path ist für Workflow-Redesign, Measurement und Rollout-Urteilsvermögen. Der Builder path ist für das Ausliefern einer ersten nützlichen Scheibe und führt inzwischen durch einen Build Reality Check, ein Build Brief, einen Build Plan, eine execution lane und ein launch gate. Unter beiden Pfaden ist das eigentliche Produkt weiterhin Assessment, Onboarding, Sprint-Progression, Review-Logik, Ressourcen, Billing, Auth und Produkt-State, die zusammenarbeiten, statt dass eine einzige AI-Chatbox so tut, als wäre sie das ganze System.

Was ist ein composed sprint in Prova?

Ein composed sprint ist ein Sprint-Paket, das für eine echte Lücke eines Learners generiert wird, wenn diese Lücke außerhalb des aktuellen authored Katalogs liegt. Die wichtige Constraint ist, dass das Modell den Standard nicht selbst erfindet. Das Paket ist dynamisch, aber submission schema und review rubric kommen weiterhin aus einem authored template sprint.

Warum wird AI Product Building nach der Demo schwieriger?

Weil das Produkt in dem Moment, in dem echte Nutzer sich anmelden, bezahlen, sich von Fehlern erholen, Arbeit einreichen und dem sichtbaren State vertrauen können, echte Versprechen macht. Ab dann zählen die unsichtbaren Systeme rund um die AI-Schicht, also Auth, Retrieval-Qualität, Evals, Billing und Operations, mehr als der beeindruckende erste Output in einer Demo.

Wenn ihr gerade mit AI baut, würde mich ehrlich interessieren:

Was war bei euch der erste Moment, in dem sich euer Projekt unangenehm real angefühlt hat, also der Punkt, an dem aus einer Demo ein Versprechen wurde?

Das war's von mir.

Cheers, Chandler