Prova を出すうえで、code は簡単なほうだった

Prova が real だと感じ始めたのは、product がもう私に自分をだます余地を残してくれなくなった瞬間でした。

Homepage は、かなり長い間 aspirational なままでいられます。

でも live product はそうはいきません。

People が signup し、email を確認し、wrong state に landing し、billing に触れ、work を submit し、そして system が何が起きたのかを正しく覚えていると期待し始めた瞬間、bottleneck は変わります。

Product は real promises を持ち始めます。そして invisible work が一気に visible になります。

3月から4月初めにかけて、Claude Max から Codex へ切り替える話を私が続けて書いていたのを読んだ人なら、あの experiment がまだ続いていることを知っていると思います。Proper な follow-up は May 2, 2026 に出すと約束しましたし、その約束は守るつもりです。これはその post ではありません。

でも Prova は、それよりも先に、もっと useful な realization を私に強制しました。

Named idea が real product になり始めると、bottleneck は変わる。

少なくとも、この build ではそう感じました。

難しかったのは LLM に code を generate させることではありませんでした。

この push で本当に難しかったのは、code の周りにある全部でした。

もし今 AI と一緒に何かを build していて、それが real users、real money、real product state に関わるものなら、これこそ nobody warns you about な部分だと思います。

もっと useful な lesson は、product が demo ではなくなった時に何が大事になるか、ということでした。

Naming は簡単だった

正直に言うと、Prova という名前を決めるのは全体の中でも easy な decision の一つでした。

この名前は product にちゃんと合っていました。

Prova は proof や test を意味します。実際、それがこの product の job です。Builder になった気分を誰かに与えるためのものではありません。Work をちゃんと prove してもらうためのものです。Nice で、useful で、searchable。つまり easy part でした。

Hard part はその直後から始まりました。Prova がただの名前や landing page ではなくなった瞬間、real products が必ず要求する unglamorous なものを全部求め始めたからです。

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

それが、AI tools と product building の両方に対する私の見方を変えました。

Prova が本当に何にならなければいけなかったのか

Prova は今、AI tools を使う側から、real workflows、pilots、operating systems を build する側へ移りたい marketers と advertising professionals のための structured AI builder program です。実際には、それは assessment と onboarding、chat-first ではなく sprint-first な product、review-driven progression、durable product state、そして generic な AI chat box ではなく、current sprint の周りで office hours のように振る舞う mentor layer を意味しました。

念のため言っておくと、私は Prova が「done」だと言っているわけではありません。そう言って move on できたら楽ですが、それは少し convenient すぎるし、おそらく正しくありません。今の right framing は soft launch です。Core production system は live で動いていますが、billing portal の return path cleanup や fuller MFA automation coverage など、intentional な launch-readiness work がまだ残っています。むしろその方が、この lesson は useful だと思います。これが real world の product building です。Finished ではない。でも fake でもない。次の mistakes に cost が生まれるくらいには real です。

Generate できなかった仕事

AI product の easiest version は demo version です。

見た目だけならすぐ alive にできます。

homepage
chat box
slick screenshots
persuasive な product sentence

それは launch teaser としては useful です。

でも real work を理解するには向いていません。

私にとって、real work が顔を出したのは六つの場所でした。

1. Sprint system が pretending をやめる必要があった

私は Prova を、landing page では structured に見えるのに、中へ入ると generic になる product にしたくありませんでした。

Fixed authored sprints は、十分な間は useful でした。

でも real problem は、learner がある sprint を pass しても、次の real gap が catalog の next authored sprint ではない時に現れました。

Lazy answer はこうです。

"Let the model invent the next sprint: title, rubric, review criteria, everything."

私はそれを trust できませんでした。

だから system はもっと strict になる必要がありました。

今の reviewer は、authored path が correct なら canonical next sprint を recommend できます。Known な foundation gap が出たら adaptive detour を assign できます。これは learner が main path に戻る前に foundation issue を fix するための temporary sprint です。そして next real gap が authored catalog の outside にある時は、composed sprint を request できます。

Blog で書くと small に見えます。

でも product の中では small ではありません。

Composed sprint は単なる dynamic text ではないからです。

Placeholder sprint を create し、assignment を persist し、canonical roadmap への return path を preserve し、sprint packet を fill し、その後 system 全体がそれを real product state として扱える必要がある。

この仕組みを still trustworthy にした constraint は simple でした。

model does not get to invent the standard.

Composed sprint が fill するのは packet だけです。title、summary、context、assignment、example。

Submission schema と review rubric は、still authored template sprint から来ます。

それが今回の build で得た biggest lessons の一つでした。

Dynamic なものを trustworthy のまま保ちたいなら、contract は fixed にして、model はその中で operate させる。私は今そう考えています。

ここは Codex がかなり役に立った場所でもありました。Flashy な "look what it generated" ではなく、もっと useful な意味で。Migrations、router logic、placeholder lifecycle、request state、integration tests。Dynamic product を less fake にする boring contract work です。

しかも私は、一瞬だけですが、lazy version に引かれました。Model に clever でいてもらえばいい。System を magical に見せればいい。後で片付ければいい。でもその考えは、paying user に bad sprint assignment を説明する自分を想像した瞬間、急に弱くなりました。

2. Retrieval は semantic なだけでは足りず、curricular である必要があった

System に composed sprints を作らせるようになると、retrieval quality は backend detail ではなくなりました。

Curriculum quality になったのです。

Tooling、measurement、competitive intelligence の sprint を compose するなら、knowledge base から "kind of related" な chunks を拾って packet が coherent に見えるよう祈る、では済みませんでした。

Knowledge base 自体が smarter になる必要がありました。

Blog posts、course modules、transcripts、companions、templates、deep-dive resources。Real corpus から全部 rebuild しました。

その上で source の種類に応じて chunking を変えました。

Narrative blog posts は larger chunks のままでいい。

Instructional modules には heading-first instructional chunks が必要。

Templates や reference assets には、tables、checklists、slide references、quick-reference sections を preserve する structured chunking が必要でした。

そして tagging です。

単に "what is this about?" ではなく、

これはどんな chunk か
どの topic tags が fit するか
どの audience 向けか
どの difficulty level に属するか

という layer が必要でした。

その結果 retrieval は "nearest vector wins" ではなく、curricular matching に近いものになりました。

Product はこう聞けるようになったわけです。

"この topic、この audience、この level に対して grounded material を出して。"

それは demo に RAG を bolt しただけのものより、ずっと serious な system でした。

3. Evals は model だけでなく pipeline を test する必要があった

これは多分、いちばん大きな learning でした。

UI 上で one composed sprint が decent に見えたからといって、victory を宣言したくなかったのです。

だから eval system も product と一緒に grow しなければならなかった。

最初は sprint review eval harness がありました。

そこに composition が retrieval gate を加えました。Tagged retrieval が untagged baseline より実際に grounded material を改善しているかを見る、basically a pass/fail check です。

さらに composition は full end-to-end harness を加えました。

sprint packet を compose する
schema-valid な synthetic submissions を generate する
それに対して real reviewer を走らせる
grounding、audience differentiation、difficulty gradient、curriculum coherence、review quality、authored work との comparability で judge する

これが real learning loop でした。

Plain English で言えば、狙いは "personalized progression" が fake personalization に落ちるのを防ぐことでした。System が "this next sprint is actually for you" と言うなら、packet が decent-looking というだけでは足りません。Grounded で、level-appropriate で、still reviewable by the same standards as the authored curriculum だという evidence が必要でした。

"model が JSON を返すか?" ではなく、

packet は grounded か
track framing は really work product を変えたか
level 2 と level 5 は materially different か
reviewer は still right pass/revise call をしたか
composed sprint は curriculum の中に belong している感覚を still 持てているか

そういう問いです。

この loop は real problems を露出させました。

Weak な synthetic revise submissions が still too strong だったり、

Audience framing が tracks across で collapse したり、

Measurement packets が fine に聞こえるのに、different learners の different trust questions に答えていなかったり。

しかも humble だったのは、UI 上で "pretty good" に見えるものが、stricter question を投げた瞬間に fail する場面を何度も見たことです。Packet は smooth に読める。でも generic すぎる。Revise case は plausible。でも easy すぎる。自分の ego には useful でした。

だから私はこの part が本当に大事だったと思います。

System が better になったのは one good prompt があったからではありません。

Product が public-to-users の前に、public-to-me な場所、つまり eval harness の中で fail できたからです。

Real learning の多くは April 8 から April 10 の tight loop にありました。

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

That sequence matters.

一つの miracle ではありませんでした。

Controlled loop でした。

4. Trust surfaces は本物でなければいけなかった

ここもまた、real products が demos と分かれる場所です。

AI layer がどれだけ elegant でも、もし

email confirmation が break する
Google sign-in が flaky
user が auth loop に trapped される
abuse controls が missing
account hardening が afterthought に見える

なら、誰も気にしません。

Prova の credibility layer は最終的にこうなりました。

right product flow に戻る email confirmation
Google SSO
optional app-based two-factor auth (TOTP MFA)
auth と assessment の Turnstile protection

People はこういう work を operational で boring に聞こえるから brag しません。

でも私は、それは mistake だと思っています。

Operational and boring な場所こそ、products が trust を earn するか、quietly lose するかの分かれ目です。

5. Billing は imaginable ではなく testable でなければならなかった

私は、monetization を one Stripe screenshot で solve したかのように語る product builders に increasingly skeptical です。

Billing はすぐ real になります。

Question は

"technically pay できるのか?"

だけではありません。

trial state の間に何が起きるか
webhook state が late に arrive したらどうなるか
自分の revenue surface で theater をせずに、どう safe に test するか
later に reliability を落とす one-off exception を invent せずに、どう whole flow を verify するか

Prova には今、real subscription flow と、safer billing verification のための internal QA checkout path があります。Minor に聞こえるかもしれません。でも違います。Product が serious になるほど、commercial logic を test しながら、自分に嘘をつかない方法が必要になります。

6. Operations は product の一部にならなければいけなかった

Prova が real だと感じた reasons の一つは、existing site に tuck した feature ではなく、different operational system として扱わなければならなかったことです。

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

Sexy な sentence ではありません。

でも、たぶんこれがいちばん重要な sentence です。

Products は UI layer だけで break するわけではありません。Systems が touch するところ、assumptions が leak するところ、environments が drift するところ、誰かが "we will fix that after launch" と言って、その after-launch version が never really comes になるところで break します。

Prova をやればやるほど、私は boring operational sentences を respect するようになりました。

自分の AI product に fast pressure test をかけたいなら、こう聞いてみてください。

model が dynamic になっても fixed のまま残す standard は何か
output を grounded に保つ retrieval は何か
user より前に fake personalization を catch する eval は何か
明日起きたら embarrassing な auth、billing、state edge はどこか

If those answers are fuzzy, product はまだ system より demo 寄りだと思います。

本当に大事な Proof

私は productization を abstractions だけで話したくありません。そうすると、実際以上に philosophical に聞こえてしまうからです。

The proof that matters most は "how many migrations did I write?" ではありません。

今、real user に対して何が actually works しているかです。

この soft-launch phase の時点で、product は credibly 次のことを言えます。

email signup と confirmation が works
Google SSO が works
optional TOTP MFA が works
downloadable resources と signed downloads が works
sprint submission と AI review が production で works
Stripe checkout handoff が works

これが buyer-facing layer の proof です。

その underneath には、repo と rollout work に基づく system proof もあります。

current production schema bootstrap に 17 Supabase migrations が applied 済み
composition retrieval のために 4,390 production knowledge-base rows が published and tagged 済み
38 downloadable resources が published 済み
tagged retrieval gate が untagged baseline に勝っている
full 18-case composition eval suite が gate を pass 済み
billing verification のための safer internal QA checkout path がある

私はこれらの numbers を、busy に見せるために並べているわけではありません。

まだ持っていないものもあります。Meaningful な batch の users が "this changed outcomes for me" と言う broad external proof はまだありません。まだ早すぎるし、そこを fake にしたくありません。

それでも numbers を並べるのは、launch language だけで語ると、「idea を product にする」ことが実際に何を意味するのかを underestimate しやすいからです。

Important なのは counts そのものではありません。

Counts が何を表しているかです。

sprint system が decorative でなくなった
retrieval が fuzzy でなくなった
evaluation が performative でなくなった
product state が rely できる程度には durable になった

Invisible work is still work.

たいてい、それが harder work です。

この経験が私の頭の中で変えたこと

AI tools が matter するとは今でも思っています。もちろんです。

Codex は、この push では useful でした。Competent で careful、methodical に感じたからです。Engineering work を move through するのに役立ちましたし、あまり emotional theater がありませんでした。Claude の方が still better だと感じるのは、work が taste-heavy で creative になる時です。

でも Prova は、それより重要な conclusion に私を押しました。

I think AI can accelerate implementation. でも product boundaries、sequencing、credibility、operational truth についての judgment を不要にはしません。

That judgment is still the work.

Landing page は product ではない。

Named concept も product ではない。

Chat interface も product ではない。

Generated component は definitely not a product です。

私にとって、何かが product っぽく感じ始めるのは、visible experience の周りに invisible architecture が立ち上がった時です。Real users が入り、pay し、progress し、block され、recover し、work を submit し、見えている state を trust し始めた瞬間、もうあなたは demo で遊んでいません。Promises をしているのです。

そして私は、product building が serious になるのは promises のところからだと思っています。

これが 4月の more useful な lesson

私はまだ May 2, 2026 の full 30-day Codex verdict を owed していますし、その日に publish するつもりです。

その post は、cost timeline、limits story、Claude に miss したもの、day-to-day working model がどう変わったかを話すのに right place です。

でも Prova は、tool comparison より durable な thing をすでに教えてくれました。

AI product building の interesting part は、rarely the demo です。

System が real promises を users にし始める point、そしてその promises のどれだけが generated code の outside に住んでいるかに気づく point。そこです。

今の私は、その part を以前より much more respect しています。

そして正直、その part こそもっと builders が話すべきだと思います。

よくある質問

Prova とは何ですか？

Prova は、AI tools を使うだけの状態から、real workflows、pilots、operating systems を build する側へ移りたい marketers と advertising professionals のための structured AI builder program です。Product としては、assessment、onboarding、sprint progression、review logic、resources、billing、auth、product state が together で動いていて、一つの AI chat box が全部のふりをしているわけではありません。

Prova の composed sprint とは何ですか？

Composed sprint は、current authored catalog の outside にある real learner gap に対して generate される sprint packet です。Important なのは、model が standard 自体を invent しないことです。Packet は dynamic ですが、submission schema と review rubric は still authored template sprint から来ます。

なぜ AI product building は demo の後の方が難しくなるのですか？

Real users が signup し、pay し、errors から recover し、work を submit し、見えている state を trust し始めた瞬間、product は promises を持ち始めます。その時点で、AI layer の周りにある invisible systems、つまり auth、retrieval quality、evals、billing、operations の方が、demo の first output が impressive に見えたかどうかより大事になります。

今 AI と一緒に何かを build しているなら、私は genuinely curious です。

あなたの project が uncomfortable なほど real に感じ始めた最初の瞬間、つまり demo が promise になった瞬間は何でしたか？

今日はここまでです。

Cheers, Chandler