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.

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, und ich habe vor, dieses Versprechen zu halten. Dieser Post ist nicht dieser Post.

Aber Prova hat mich früher als erwartet zu einer nützlicheren Erkenntnis gezwungen:

Sobald etwas aufhört, nur eine benannte Idee zu sein, und beginnt, ein echtes Produkt zu werden, verändert sich der Bottleneck.

Zumindest hat es sich in diesem Build genau so angefühlt.

Der schwierige Teil war nicht, ein LLM Code generieren zu lassen.

Der schwierige Teil war, jedenfalls in diesem Push für mich, 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.

Die nützlichere Lektion ist: Was wird wichtig, sobald ein Produkt aufhört, nur eine Demo zu sein?

Der Name war der einfache Teil

Ich muss zugeben: Prova zu benennen war eine der einfacheren Entscheidungen im ganzen Prozess.

Der Name passte einfach wirklich zum Produkt.

Prova heißt im Kern so etwas wie Beweis oder Test. Und genau das ist im Grunde der Job des Produkts. Es soll Menschen nicht schmeicheln und ihnen das Gefühl geben, sie seien schon Builder. Es soll sie dazu bringen, die Arbeit auch wirklich zu beweisen. Schön, brauchbar, suchbar. Anders gesagt: der einfache Teil.

Der schwerere Teil begann direkt danach. Denn 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 strukturiertes AI-Builder-Programm für Marketer und Werbeprofis, die von "AI-Tools benutzen" zu "echte Workflows, Piloten und Betriebssysteme bauen" wechseln wollen. Praktisch bedeutete das Assessment und Onboarding, ein sprint-first Produkt statt eines chat-first Produkts, 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 ehrlichere Einordnung heute ist Soft Launch: Das Kernsystem in Production ist live und funktioniert, aber auf der Liste stehen immer noch absichtliche Launch-Readiness-Themen, darunter Cleanup für den Billing-Portal-Return-Path und umfassendere MFA-Automation-Abdeckung. Ich glaube sogar, dass die Lektion dadurch nützlicher wird. 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

Das war für mich vielleicht die wichtigste Lektion von allen.

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
• die Ergebnisse nach grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality und Vergleichbarkeit mit authored work beurteilen

Das war die eigentliche Lernschleife.

In normalem Deutsch gesagt: 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, dass der Sprint grounded ist, zum Niveau passt und mit denselben Standards reviewbar bleibt wie das authored Curriculum.

Nicht: "Gibt das Modell JSON zurück?"

Sondern eher:

• 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.

Und genau deshalb halte ich diesen Teil für so wichtig.

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.

Viel der eigentlichen Lernarbeit lag in einer engen Schleife vom 8. bis 10. April:

• schema groundwork
• composed sprint lifecycle
• tagged knowledge rebuild
• retrieval gate
• composition calibration
• full eval pass
• integration coverage
• browser QA im live flow

Diese Reihenfolge ist wichtig.

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.

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

Dieser Abschnitt ist nicht sexy. Er ist auch wahrscheinlich der wichtigste Abschnitt im ganzen Post.

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 und confirmation 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 funktioniert

Das ist die buyer-facing Schicht von Beweis.

Darunter gibt es auch Systembeweise aus Repo und Rollout:

• 17 Supabase-Migrations durch den aktuellen Production-Schema-Bootstrap
• 4,390 Production-Knowledge-Base-Rows, veröffentlicht und für Composition Retrieval getaggt
• 38 downloadable resources veröffentlicht
• 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

Ich nenne diese Zahlen nicht, um beschäftigt zu wirken.

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.

Aber Prova hat mich zu einer wichtigeren Schlussfolgerung geschoben:

Ich glaube, 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.

Ein Chat-Interface 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.

Und ich glaube, Versprechen sind der Punkt, an dem Product Building ernst wird.

Das ist die nützlichere April-Lektion

Ich schulde euch immer noch das volle 30-Tage-Codex-Urteil am May 2, 2026, und ich habe vor, es dann auch zu veröffentlichen.

Dieser Post wird der richtige Ort für die Kosten-Zeitleiste, die Limits-Story, das, was ich an Claude vermisst habe, und das, was sich in meinem täglichen Arbeitsmodell verändert hat.

Aber Prova hat mir jetzt schon etwas Dauerhafteres beigebracht als jeder Tool-Vergleich:

Der interessante Teil von AI Product Building ist selten die Demo.

Es ist der Punkt, an dem dein System beginnt, echte Versprechen an Nutzer zu machen, und du merkst, wie viele dieser Versprechen außerhalb des generierten Codes leben.

Diesen Teil respektiere ich heute mehr.

Und ehrlich gesagt glaube ich, dass viel mehr Builder darüber sprechen sollten.

Häufige Fragen

Was ist Prova?

Prova ist ein strukturiertes AI-Builder-Programm für Marketer und Werbeprofis, die von der Nutzung von AI-Tools zum Bau echter Workflows, Piloten und Betriebssysteme wechseln wollen. In Produktbegriffen bedeutet das: Assessment, Onboarding, Sprint-Progression, Review-Logik, Ressourcen, Billing, Auth und Produkt-State arbeiten zusammen, 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