Ang code ang mas madaling bahagi ng pag-ship ng Prova

Naging totoo sa akin ang Prova noong tumigil na ang produkto sa pagpayag na lokohin ko ang sarili ko.

Kayang manatiling aspirational ng isang homepage nang matagal.

Ang isang live na produkto, hindi.

Sa oras na puwede nang mag-sign up ang mga tao, mag-confirm ng email, mapunta sa maling state, tumama sa billing, magsumite ng work, at umasa na maaalala ng system ang nangyari, nagbabago ang bottleneck.

Nagsisimula nang gumawa ng tunay na pangako ang produkto. At ang invisible work, biglang nagiging sobrang visible.

Kung nabasa mo ang tatlong posts ko noong March at early April tungkol sa paglipat ko mula Claude Max papuntang Codex, tuloy pa rin ang experiment na iyon. Nangako na ako ng maayos na follow-up sa May 2, 2026, at balak kong tuparin iyon. Hindi ito ang post na iyon.

Pero mas maaga kaysa inaasahan, pinwersa ako ng Prova na makita ang isang mas useful na realization:

Kapag ang isang bagay ay tumigil nang maging isang ideyang may pangalan at nagsimulang maging totoong produkto, nagbabago ang bottleneck.

At least, iyon ang pakiramdam nito sa build na ito.

Hindi ang pagkuha sa LLM na mag-generate ng code ang mahirap.

Ang mahirap, para sa akin sa push na ito, ay lahat ng nakapaligid sa code.

Kung may binubuo ka gamit ang AI ngayon, lalo na kung may kinalaman ito sa real users, real money, o real product state, pakiramdam ko ito ang bahagi na halos walang nagbababala sa iyo.

Ang mas useful na lesson ay ito: ano ang nagsisimulang maging mahalaga kapag ang isang produkto ay hindi na lang demo.

Ang pangalan ang madaling bahagi

Aaminin ko: isa ang pagpapangalan sa Prova sa mas madadaling desisyon sa buong prosesong ito.

Pumuwesto agad ang pangalan dahil talagang tugma ito sa produkto.

Ibig sabihin ng Prova ay proof o test. At iyon mismo ang trabaho ng produkto. Hindi ito para bolahin ang tao at iparamdam na builder na sila agad. Nandito ito para ipamukha na kailangan nilang patunayan ang work nila. Maganda, useful, searchable. Sa madaling salita, iyon ang easy part.

Ang mas mahirap na bahagi ay nagsimula pagkatapos noon. Dahil noong tumigil ang Prova sa pagiging pangalan at landing page lang, nagsimula itong humingi ng lahat ng hindi glamoroso pero totoong hinihingi ng mga tunay na produkto:

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

Binago niyon ang paraan ko ng pag-iisip tungkol sa AI tools at pati sa product building.

Ano ang talagang kinailangan maging Prova

Prova ay isa nang structured AI builder program para sa marketers at advertising professionals na gustong lumipat mula sa paggamit ng AI tools tungo sa pagbuo ng totoong workflows, pilots, at operating systems. Sa praktikal na level, ibig sabihin nito ay assessment at onboarding, isang sprint-first na produkto sa halip na chat-first, review-driven progression, durable product state, at mentor layer na mas kahawig ng office hours sa paligid ng kasalukuyang sprint kaysa generic na AI chat box.

Para malinaw: hindi ko sinasabing "tapos na" ang Prova. Gusto ko sanang masabi iyon at move on na, pero magiging sobrang convenient niyan, at malamang hindi rin totoo. Ang tamang framing ngayon ay soft launch: live at gumagana na ang core production system, pero may intentional launch-readiness work pa rin sa listahan, kasama ang billing portal return-path cleanup at mas buong coverage para sa MFA automation. Sa tingin ko, iyon pa nga ang dahilan kung bakit mas useful ang lesson. Ganito ang hitsura ng product building sa totoong mundo. Hindi pa tapos. Hindi fake. Sapat lang ang pagkatotoo para may kapalit na ang susunod na pagkakamali.

Ang trabahong hindi ko basta na-generate

Ang pinakamadaling bersyon ng isang AI product ay halos laging ang demo version.

Madali mo itong mapagmukhang buhay:

isang homepage
isang chat box
ilang makikinis na screenshots
isang nakakahikayat na product sentence

Useful iyon para sa launch teaser.

Hindi iyon gaanong useful kung gusto mong maintindihan kung nasaan ang tunay na work.

Para sa akin, lumitaw ang totoong work sa anim na lugar.

1. Kailangan tumigil sa pagpapanggap ng sprint system

Ayokong maging isa na namang produkto ang Prova na mukhang structured sa landing page pero generic pala pagpasok ng tao sa loob.

Nakatulong ang fixed authored sprints hanggang sa dumating ang puntong hindi na sapat.

Lumabas ang tunay na problema nang makapasa ang learner sa isang sprint, pero ang susunod niyang tunay na gap ay hindi pala ang next authored sprint sa catalog.

Ang tamad na sagot sana ay:

"Hayaan na lang nating mag-imbento ang model ng susunod na sprint: title, rubric, review criteria, lahat."

Hindi ko pinaniwalaan iyon.

Kaya kinailangan maging mas istrikto ang system.

Ngayon, kaya pa ring irekomenda ng reviewer ang canonical next sprint kapag tama ang authored path. Kaya rin nitong mag-assign ng adaptive detour, ibig sabihin ay temporary sprint para maayos muna ang foundation gap bago bumalik sa pangunahing path. At kung ang susunod na totoong gap ay nasa labas ng authored catalog, puwede itong humiling ng composed sprint.

Maliit itong pakinggan sa blog post.

Sa produkto, hindi ito maliit.

Dahil ang composed sprint ay hindi lang "dynamic text."

Kailangan nitong gumawa ng placeholder sprint, i-persist ang assignment, panatilihin ang return path pabalik sa canonical roadmap, punuin ang sprint packet, at hayaang tratuhin ng natitirang system ang sprint na iyon bilang tunay na product state.

Simple lang ang constraint na nagpanatiling mapagkakatiwalaan ito:

hindi puwedeng ang model ang mag-imbento ng standard.

Packet lang ang pinupunan ng composed sprint: title, summary, context, assignment, example.

Ang submission schema at review rubric ay galing pa rin sa authored template sprint.

Isa iyon sa pinakamalalaking aral sa buong build na ito.

Kung gusto mong manatiling mapagkakatiwalaan ang isang dynamic na bagay, panatilihing fixed ang contract at hayaan ang model na gumalaw sa loob nito.

Dito rin malaki ang naitulong ng Codex sa akin. Hindi sa flashy na paraan na "tingnan mo ang na-generate nito." Kundi sa mas useful na paraan: migrations, router logic, placeholder lifecycle, request state, integration tests, at lahat ng boring contract work na nagpapabawas sa pagka-fake ng isang dynamic na produkto.

At kailangan ko ring aminin na natukso ako, kahit sandali, sa mas tamad na bersyon. Hayaan lang ang model na maging clever. Hayaan ang system na magmukhang magical. Ayusin na lang mamaya. Maganda iyang pakinggan hanggang sa maisip mong kailangan mong ipaliwanag ang isang bad sprint assignment sa isang paying user.

2. Kailangan maging curricular ang retrieval, hindi lang semantic

Noong pinayagan ko na ang system na mag-compose ng sprints, tumigil na ang retrieval quality sa pagiging backend detail.

Naging curriculum quality na ito.

Kung magko-compose ang produkto ng sprint tungkol sa tooling, measurement, o competitive intelligence, hindi puwedeng kumuha lang ito ng "medyo related" na chunks mula sa knowledge base at umasang magiging coherent ang packet.

Kailangang maging mas matalino ang knowledge base.

Binuilt namin itong muli mula sa totoong corpus: blog posts, course modules, transcripts, companions, templates, at deep-dive resources.

Pagkatapos, iba-iba ang pag-chunk namin depende sa uri ng source.

Puwedeng manatiling mas malaki ang narrative blog posts.

Kailangan ng heading-first chunks ang instructional modules.

Kailangan naman ng mas structured na chunking ang templates at reference assets para mapanatili ang tables, checklists, slide references, at quick-reference sections sa halip na maging generic paragraphs ang lahat.

Pagkatapos, naging mahalaga ang tagging.

Hindi lang "tungkol saan ito?" kundi pati:

anong uri ng chunk ito
anong topic tags ang akma
para saang audience ito
anong difficulty level ito nababagay

Binago niyan ang retrieval mula sa "nearest vector wins" patungo sa isang bagay na mas kahawig ng curricular matching.

Puwede nang magtanong ang produkto ng ganito:

"Bigyan mo ako ng grounded material para sa topic na ito, para sa audience na ito, sa level na ito."

Mas seryosong system iyon kaysa basta idikit lang ang RAG sa demo.

3. Kailangan i-test ng evals ang buong pipeline, hindi lang ang model

Ito siguro ang pinakamahalagang lesson sa lahat.

Ayokong ideklarang panalo na dahil lang may isang composed sprint na mukhang maayos sa UI.

Kaya kinailangang lumaki kasama ng produkto ang eval system.

Una, nandoon ang sprint review eval harness.

Pagkatapos, nagdagdag ang composition ng retrieval gate, basically isang pass/fail check para makita kung talagang mas gumaganda ang grounded material kapag tagged retrieval kumpara sa untagged baseline.

Pagkatapos, nagdagdag ang composition ng full end-to-end harness:

i-compose ang sprint packet
mag-generate ng schema-valid synthetic submissions
patakbuhin ang tunay na reviewer laban sa mga submission na iyon
i-judge ang resulta sa grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality, at comparison laban sa authored work

Iyon ang totoong learning loop.

Sa payak na salita, ang punto nito ay pigilan ang "personalized progression" na maging fake personalization. Kung sasabihin ng system na "para talaga sa iyo ang next sprint na ito," kailangan nito ng higit pa sa packet na mukhang maayos. Kailangan nito ng ebidensiya na grounded ang sprint, akma sa level, at puwede pa ring i-review gamit ang parehong standard ng authored curriculum.

Hindi "nakakabalik ba ng JSON ang model?"

Kundi:

grounded ba ang packet
talagang nababago ba ng track framing ang work product
ramdam ba ang pagkakaiba ng level 2 at level 5
tama pa rin ba ang pass/revise call ng reviewer
pakiramdam ba ay bahagi pa rin ng curriculum ang composed sprint sa halip na nakalutang lang sa tabi

Naglantad ang loop na iyon ng totoong problema.

Mga revise submission na mahina pero masyado pa ring malakas.

Audience framing na bumabagsak kapag nagpalipat-lipat ng track.

Measurement packets na maayos pakinggan pero hindi talaga sumasagot sa magkaibang trust questions para sa magkaibang learner.

Isa sa mga pinakanakakapagpakumbabang moment para sa akin ay ang mapansing gaano kadalas may bagay na "mukhang okay naman" sa UI pero bumibigay agad kapag tinanong ko nang mas mahigpit. Puwedeng maayos basahin ang packet pero sobra pa ring generic. Puwedeng plausible ang revise case pero masyado pa ring madali. Mabuti rin iyon para sa ego ko, sa tingin ko.

At iyon ang dahilan kung bakit mahalaga talaga ang bahaging ito.

Hindi gumanda ang system dahil lang may isang magandang prompt ako.

Gumanda ito dahil puwede munang mag-fail ang produkto sa harap ko, sa loob ng eval harness, bago ito mag-fail sa harap ng users.

Marami sa totoong learning ang nangyari sa masikip na loop noong April 8 hanggang April 10:

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

Mahalaga ang sequence na iyan.

Hindi ito isang himala. Isa itong controlled loop.

4. Kailangan maging totoo ang mga trust surface

Dito rin malinaw na naghihiwalay ang totoong produkto sa demo.

Walang may pakialam kung gaano ka-elegant ang AI layer mo kung:

sira ang email confirmation
flaky ang Google sign-in
naiipit ang user sa auth loop
kulang ang abuse controls
mukhang huling idinugtong lang ang account hardening

Para sa Prova, ang credibility layer na ito ay nauwi sa:

email confirmation na ibinabalik ang tao sa tamang product flow
Google SSO
optional app-based two-factor auth (TOTP MFA)
Turnstile protection sa auth at assessment

Ito ang uri ng work na bihirang ipagmayabang dahil tunog operational at boring.

Sa tingin ko, pagkakamali iyon.

Sa operational at boring na bahagi kadalasang nananalo o tahimik na natatalo ang tiwala sa produkto.

5. Kailangan maging testable ang billing, hindi lang imaginable

Palaki nang palaki ang pagdududa ko sa mga builder na nagsasalita tungkol sa monetization na parang isang Stripe screenshot lang ang layo nito sa pagiging solved.

Mabilis maging totoo ang billing.

Hindi lang ito tungkol sa:

"May makakabayad ba, technically?"

Kundi tungkol din sa:

ano ang nangyayari habang nasa trial state
ano ang nangyayari kapag late dumating ang webhook state
paano mag-test nang ligtas nang hindi nagte-theater sa sarili mong revenue surface
paano i-verify ang buong flow nang hindi nag-iimbento ng one-off exceptions na magpapahina sa system sa bandang huli

May totoong subscription flow na ngayon ang Prova, kasama ang internal QA checkout path na sadyang para sa mas ligtas na billing verification. Mukha itong maliit. Hindi. Habang mas nagiging seryoso ang produkto, mas kailangan mo ng paraan para subukan ang commercial logic nang hindi mo niloloko ang sarili mo tungkol sa na-verify mo na at hindi pa.

6. Kailangan maging bahagi ng produkto ang operations

Isa sa mga dahilan kung bakit naging tunay sa akin ang Prova ay kailangan ko na itong tratuhin bilang hiwalay na operational system, hindi bilang feature na nakatupi lang sa lumang site ko.

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

Hindi sexy ang pangungusap na iyan. Pero posibleng iyan din ang pinakamahalaga.

Dahil hindi lang sa UI nababasag ang mga produkto. Nababasag sila kung saan nagtatagpo ang systems, kung saan tumatagas ang assumptions, kung saan lumilihis ang environments, kung saan may nagsasabing "aayusin natin iyan after launch" tapos hindi naman talaga dumarating ang after-launch version.

Habang mas tumatagal akong nagtatrabaho sa Prova, mas gumagalang ako sa mga boring operational sentences.

Kung gusto mo ng mabilis na pressure test para sa sarili mong AI product, itanong mo:

anong standard ang nananatiling fixed habang nagiging dynamic ang model
anong retrieval ang nagpapanatiling grounded ng output
anong eval ang huhuli sa fake personalization bago pa mapansin ng user
aling auth, billing, o state edge ang ikahihiya mo bukas

Kung malabo pa rin ang mga sagot, malamang mas demo pa rin ito kaysa system.

Ang Proof na Talagang Mahalaga

Ayokong puro abstraction lang ang pag-uusap tungkol sa productization, dahil kung hindi ay parang mas philosophical kaysa totoo ang dating.

Ang proof na pinakamahalaga ay hindi "ilang migrations ang naisulat ko?"

Ang tanong ay: ano ang gumagana na ngayon para sa totoong user?

Sa soft-launch phase na ito, puwede nang sabihin ng produkto nang may kredibilidad:

gumagana ang email signup at confirmation
gumagana ang Google SSO
gumagana ang optional TOTP MFA
gumagana ang downloadable resources at signed downloads
gumagana sa production ang sprint submission at AI review
gumagana ang Stripe checkout handoff

Iyan ang buyer-facing na layer ng proof.

Sa ilalim niyan, may system proof din mula sa repo at rollout work:

17 Supabase migrations na naisagawa sa current production schema bootstrap
4,390 production knowledge-base rows na na-publish at na-tag para sa composition retrieval
38 downloadable resources na na-publish
tagged retrieval gate na lumalamang sa untagged baseline
full 18-case composition eval suite na pumapasa sa gate
mas ligtas na internal QA checkout path para sa billing verification

Hindi ko inililista ang mga numerong ito para magmukhang busy.

Ang wala pa sa akin ay malawak na external proof mula sa meaningful batch ng users na nagsasabing, "binago nito ang outcomes ko." Maaga pa para doon, at ayokong pekein iyon.

Inililista ko sila dahil napakadaling maliitin kung ano talaga ang ibig sabihin ng "gawing produkto ang isang ideya" kapag puro launch language lang ang gamit mo.

Hindi ang count mismo ang mahalaga.

Ang mahalaga ay ang ibig sabihin ng mga count na iyon:

tumigil na sa pagiging dekorasyon ang sprint system
tumigil nang maging malabo ang retrieval
tumigil nang maging performative ang evaluation
naging sapat na ang tibay ng product state para pagtiwalaan

Trabaho pa rin ang invisible work.

At madalas, iyon ang mas mahirap na trabaho.

Ano ang binago nito sa isip ko

Naniniwala pa rin akong mahalaga ang AI tools. Siyempre naman.

Naging useful ang Codex sa push na ito dahil pakiramdam ko competent, maingat, at methodical ito. Nakakatulong itong itulak ako sa engineering work nang walang masyadong emotional theater. Mas magaling pa rin sa panlasa ko si Claude kapag mas taste-heavy at creative ang trabaho.

Pero tinulak ako ng Prova sa isang mas mahalagang konklusyon:

Sa tingin ko, napapabilis ng AI ang implementation, pero hindi nito inaalis ang pangangailangan sa judgment tungkol sa product boundaries, sequencing, credibility, at operational truth.

Iyong judgment na iyon ang trabaho.

Hindi produkto ang landing page.

Hindi produkto ang concept na may pangalan.

Hindi produkto ang chat interface.

At lalong hindi produkto ang generated component.

Para sa akin, ang nagpaparamdam na produkto na nga ang isang bagay ay ang invisible architecture sa paligid ng visible experience. Sa sandaling kaya nang pumasok, magbayad, mag-progress, ma-block, makabawi, magsumite ng work, at magtiwala sa nakikitang state ang totoong users, hindi ka na naglalaro ng demo. Gumagawa ka na ng mga pangako.

At sa tingin ko, sa mga pangakong iyon nagiging seryoso ang product building.

Ito ang mas useful na April lesson

Utang ko pa rin ang full 30-day Codex verdict sa May 2, 2026, at balak kong i-publish iyon sa petsang iyon.

Iyon ang tamang post para sa cost timeline, sa limits story, sa mga nami-miss ko kay Claude, at sa mga nagbago sa araw-araw kong working model.

Pero may naituro na agad sa akin ang Prova na mas matibay kaysa anumang tool comparison:

Bihirang ang demo ang interesting na bahagi ng AI product building.

Mas interesting ang sandaling nagsisimulang gumawa ng totoong pangako ang system mo sa users, at napapansin mong marami sa mga pangakong iyon ay nakatira sa labas ng generated code.

Mas nirerespeto ko ang bahaging iyon ngayon.

At sa totoo lang, sa tingin ko mas maraming builders ang dapat magsalita tungkol dito.

Mga Madalas Itanong

Ano ang Prova?

Ang Prova ay isang structured AI builder program para sa marketers at advertising professionals na gustong lumipat mula sa paggamit ng AI tools patungo sa pagbuo ng totoong workflows, pilots, at operating systems. Sa terms ng produkto, ibig sabihin nito ay assessment, onboarding, sprint progression, review logic, resources, billing, auth, at product state na nagtutulungan, sa halip na isang AI chat box na nagpapanggap na siya na ang buong system.

Ano ang composed sprint sa Prova?

Ang composed sprint ay sprint packet na ginawa para sa totoong learner gap na nasa labas ng current authored catalog. Ang mahalagang constraint ay hindi ang model ang nag-iimbento ng standard nang mag-isa. Dynamic ang packet, pero galing pa rin sa authored template sprint ang submission schema at review rubric.

Bakit mas humihirap ang AI product building pagkatapos ng demo?

Dahil sa oras na puwede nang mag-sign up, magbayad, makabawi mula sa errors, magsumite ng work, at magtiwala sa state na nakikita nila ang totoong users, nagsisimula nang gumawa ng pangako ang produkto. Sa puntong iyon, mas mahalaga na ang mga invisible systems sa paligid ng AI layer, gaya ng auth, retrieval quality, evals, billing, at operations, kaysa sa impressive na unang output sa demo.

Kung may ginagawa ka gamit ang AI ngayon, totoong gusto kong malaman:

ano ang unang sandali na naging nakakailang sa sobrang totoo ng project mo, ang sandali na ang demo ay naging pangako?

Hanggang dito na muna ako.

Cheers, Chandler