Code Ternyata Bagian Termudah Saat Meluncurkan Prova

Prova mulai terasa nyata buat saya ketika produk ini berhenti membiarkan saya membohongi diri sendiri.

Sebuah homepage bisa bertahan lama dalam mode aspirational.

Produk yang benar-benar live tidak bisa.

Begitu orang bisa signup, confirm email, mendarat di tempat yang salah, menyentuh billing state, submit work, lalu berharap sistem mengingat apa yang terjadi, bottleneck-nya berubah.

Produk mulai membuat janji yang nyata. Dan pekerjaan yang tadinya tidak kelihatan langsung jadi sangat kelihatan.

Kalau kamu mengikuti tiga post saya di bulan Maret dan awal April soal pindah dari Claude Max ke Codex, eksperimen itu masih berjalan. Saya sudah janji akan menulis follow-up yang proper pada May 2, 2026, dan saya berniat menepati janji itu. Post ini bukan post itu.

Tapi Prova memaksa saya melihat sesuatu yang lebih berguna lebih cepat dari yang saya kira:

Begitu sesuatu berhenti menjadi ide yang punya nama, lalu mulai jadi produk sungguhan, bottleneck-nya ikut berubah.

Setidaknya, itulah rasanya di build ini.

Bagian sulitnya bukan membuat LLM generate code.

Bagian sulitnya, setidaknya di push kali ini, adalah semua hal di sekitar code.

Kalau kamu sedang membangun dengan AI sekarang, terutama sesuatu yang menyangkut pengguna nyata, uang nyata, atau product state yang nyata, saya rasa inilah bagian yang paling jarang diperingatkan orang.

Pelajaran yang lebih berguna adalah: apa yang mulai penting ketika sebuah produk berhenti jadi sekadar demo.

Menamai Produk Itu Bagian yang Mudah

Saya harus mengakui, memberi nama Prova termasuk salah satu keputusan termudah di seluruh proses ini.

Namanya terasa pas karena memang cocok dengan produknya.

Prova berarti proof atau test. Dan pada dasarnya memang itu tugas produknya. Produk ini bukan dibuat untuk menepuk pundak orang lalu membuat mereka merasa sudah jadi builder. Produk ini dibuat untuk memaksa orang membuktikan pekerjaannya. Nama yang enak, berguna, gampang dicari. Dengan kata lain, itulah bagian yang mudah.

Bagian yang sulit mulai terasa setelah itu. Karena saat Prova berhenti jadi sekadar nama dan landing page, ia mulai menuntut semua pekerjaan yang tidak glamor tapi memang dituntut oleh produk sungguhan:

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

Itu mengubah cara saya memikirkan AI tools, dan juga cara saya memikirkan product building.

Sebenarnya Prova Harus Menjadi Apa

Prova sekarang adalah program AI builder yang terstruktur untuk marketer dan advertising professionals yang ingin bergerak dari sekadar memakai AI tools menuju membangun workflow, pilot, dan operating system yang nyata. Secara praktik, itu berarti assessment dan onboarding, produk yang sprint-first alih-alih chat-first, progression yang digerakkan oleh review, product state yang tahan lama, dan mentor layer yang lebih terasa seperti office hours di sekitar sprint yang sedang dijalani daripada AI chat box yang generik.

Biar jelas: saya tidak sedang bilang Prova sudah "selesai". Saya juga ingin sekali bisa bilang begitu lalu move on, tapi itu akan terasa terlalu nyaman, dan mungkin juga tidak benar. Framing yang jujur hari ini adalah soft launch: core production system-nya sudah live dan berfungsi, tetapi masih ada launch-readiness work yang memang sengaja belum selesai, termasuk cleanup untuk billing portal return path dan coverage yang lebih lengkap untuk MFA automation. Menurut saya justru itu yang membuat pelajarannya lebih berguna. Beginilah bentuk product building di dunia nyata. Belum selesai. Bukan fake. Cuma sudah cukup nyata sampai kesalahan berikutnya mulai ada harganya.

Pekerjaan yang Tidak Bisa Saya Generate Begitu Saja

Versi termudah dari sebuah AI product hampir selalu versi demo.

Kamu bisa membuatnya terlihat hidup dengan cepat:

sebuah homepage
sebuah chat box
beberapa screenshot yang slick
satu kalimat positioning yang meyakinkan

Itu berguna untuk teaser launch.

Tapi tidak terlalu berguna kalau kamu ingin tahu di mana pekerjaan yang sebenarnya.

Buat saya, pekerjaan yang sebenarnya mulai muncul di enam tempat.

1. Sistem sprint harus berhenti pura-pura

Saya tidak mau Prova menjadi produk yang terlihat terstruktur di landing page, lalu berubah jadi generik begitu orang masuk ke dalam.

Fixed authored sprints berguna sampai titik tertentu. Lalu mereka berhenti cukup.

Masalah sebenarnya muncul ketika seorang learner lulus dari sebuah sprint, tetapi gap nyata berikutnya ternyata bukan authored sprint berikutnya di katalog.

Jawaban yang malas akan terdengar seperti ini:

"Ya sudah, biarkan model mengarang sprint berikutnya: title, rubric, review criteria, semuanya."

Saya tidak percaya pada pendekatan itu.

Jadi sistemnya harus dibuat lebih ketat.

Sekarang reviewer masih bisa merekomendasikan canonical next sprint ketika authored path memang benar. Ia bisa memberi adaptive detour, yaitu sprint sementara yang membantu learner memperbaiki foundation gap sebelum kembali ke jalur utama. Dan ketika gap berikutnya memang berada di luar authored catalog, ia bisa meminta composed sprint.

Di blog post, itu terdengar kecil.

Di dalam produk, itu tidak kecil.

Karena composed sprint bukan sekadar "teks dinamis".

Ia harus membuat placeholder sprint, menyimpan assignment, menjaga return path ke roadmap yang canonical, mengisi sprint packet, lalu membiarkan seluruh sistem memperlakukan sprint itu sebagai product state yang nyata.

Constraint yang membuat semuanya tetap bisa dipercaya sebenarnya sederhana:

model tidak boleh menemukan standarnya sendiri.

Composed sprint hanya mengisi packet: title, summary, context, assignment, example.

Submission schema dan review rubric tetap datang dari authored template sprint.

Itu salah satu pelajaran terbesar dari seluruh build ini.

Kalau kamu ingin sesuatu yang dinamis tetap bisa dipercaya, jagalah contract-nya tetap fixed dan biarkan model bekerja di dalam contract itu.

Di titik ini juga Codex banyak membantu saya. Bukan dengan cara flashy seperti "lihat nih, dia generate apa". Tetapi dengan cara yang jauh lebih berguna: migrations, router logic, placeholder lifecycle, request state, integration tests, dan seluruh pekerjaan kontrak yang membosankan tapi membuat produk dinamis terasa tidak terlalu fake.

Dan saya juga harus jujur: versi yang malas itu sempat menggoda. Biarkan model terlihat clever. Biarkan sistem terasa magical. Rapikan nanti. Ide itu terdengar menyenangkan sampai kamu membayangkan harus menjelaskan bad sprint assignment ke pengguna yang membayar.

2. Retrieval harus jadi curricular, bukan cuma semantic

Begitu saya membiarkan sistem compose sprints, kualitas retrieval berhenti jadi detail backend.

Ia berubah jadi kualitas curriculum.

Kalau produk ini mau menyusun sprint tentang tooling, measurement, atau competitive intelligence, ia tidak bisa hanya menarik chunks yang "lumayan terkait" dari knowledge base lalu berharap packet-nya terasa coherent.

Knowledge base-nya sendiri harus jadi lebih cerdas.

Kami membangunnya ulang dari corpus yang nyata: blog posts, course modules, transcripts, companions, templates, dan deep-dive resources.

Lalu kami meng-chunk sumber-sumber itu secara berbeda sesuai jenisnya.

Blog post yang naratif boleh tetap lebih besar.

Instructional modules perlu heading-first chunks.

Templates dan reference assets perlu chunking yang lebih terstruktur, supaya tables, checklists, slide references, dan quick-reference sections tidak diratakan jadi paragraf generik.

Setelah itu, tagging jadi penting.

Bukan cuma "ini tentang apa?" tapi juga:

ini chunk jenis apa
topic tags mana yang cocok
audience mana yang paling pas
difficulty level berapa

Itu mengubah retrieval dari "nearest vector wins" menjadi sesuatu yang lebih mirip curricular matching.

Produk bisa bertanya seperti:

"Kasih saya grounded material untuk topic ini, untuk audience ini, di level ini."

Itu sistem yang jauh lebih serius daripada sekadar menempelkan RAG ke demo.

3. Evals harus menguji pipeline, bukan cuma model

Ini mungkin pelajaran terpenting dari semuanya.

Saya tidak ingin merasa menang hanya karena satu composed sprint terlihat lumayan di UI.

Jadi sistem eval-nya harus tumbuh bersama produknya.

Pertama ada sprint review eval harness.

Lalu composition menambahkan retrieval gate, pada dasarnya pass/fail check untuk melihat apakah tagged retrieval benar-benar meningkatkan grounded material dibanding baseline yang tidak ditag.

Lalu composition menambahkan harness end-to-end penuh:

compose sprint packet
generate synthetic submissions yang masih valid terhadap schema
jalankan reviewer sungguhan terhadap submissions itu
nilai hasilnya di grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality, dan comparison terhadap authored work

Di situlah learning loop yang sebenarnya.

Kalau dibilang dengan bahasa sederhana, tujuannya adalah mencegah "personalized progression" berubah jadi fake personalization. Kalau sistem mau bilang "sprint berikutnya ini memang untuk kamu", maka ia butuh lebih dari sekadar packet yang tampak rapi. Ia butuh bukti bahwa sprint itu grounded, sesuai level, dan tetap bisa direview dengan standard yang sama seperti curriculum authored.

Bukan "model-nya bisa mengembalikan JSON atau tidak?"

Lebih seperti:

apakah packet-nya tetap grounded
apakah track framing-nya benar-benar mengubah work product
apakah level 2 dan level 5 terasa berbeda secara nyata
apakah reviewer masih mengambil keputusan pass/revise yang tepat
apakah composed sprint itu masih terasa bagian dari curriculum, bukan benda asing yang mengambang di sampingnya

Loop itu membuka masalah yang nyata.

Revise submissions yang lemah tapi masih terlalu kuat.

Audience framing yang runtuh di antara track.

Measurement packets yang terdengar oke, tapi tidak benar-benar menjawab trust questions yang berbeda untuk learner yang berbeda.

Salah satu momen yang paling merendahkan buat saya adalah menyadari betapa sering sesuatu bisa terlihat "cukup bagus" di UI, tapi tetap gagal begitu saya ajukan pertanyaan yang lebih keras. Sebuah packet bisa terbaca mulus dan tetap terlalu generik. Sebuah revise case bisa terasa masuk akal dan tetap terlalu mudah. Itu cukup bagus buat ego saya, saya rasa.

Dan itulah kenapa bagian ini terasa penting.

Sistemnya tidak membaik karena saya punya satu prompt yang bagus.

Sistemnya membaik karena produk ini bisa gagal dulu di depan saya, di dalam eval harness, sebelum gagal di depan pengguna sungguhan.

Banyak pembelajaran nyata terjadi di loop yang rapat antara 8 sampai 10 April:

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

Urutan itu penting.

Ini bukan satu keajaiban. Ini loop yang terkontrol.

4. Titik-titik kepercayaan harus benar-benar nyata

Di sini juga produk nyata mulai terpisah dari demo.

Tidak ada yang peduli seberapa elegan AI layer-mu kalau:

email confirmation rusak
Google sign-in goyah
user terjebak di auth loop
abuse controls tidak ada
account hardening terasa seperti tambahan belakangan

Untuk Prova, credibility layer ini akhirnya mencakup:

email confirmation yang mengembalikan orang ke product flow yang benar
Google SSO
optional app-based two-factor auth (TOTP MFA)
proteksi Turnstile pada auth dan assessment

Ini jenis pekerjaan yang jarang dibanggakan orang karena terdengar operasional dan membosankan.

Saya rasa itu kesalahan.

Justru di wilayah yang operasional dan membosankan itulah produk mendapatkan kepercayaan atau kehilangannya secara diam-diam.

5. Billing harus bisa diuji, bukan cuma dibayangkan

Saya makin skeptis pada builder yang bicara soal monetization seolah semuanya tinggal sejauh satu screenshot Stripe dari selesai.

Billing jadi nyata dengan sangat cepat.

Pertanyaannya bukan cuma:

"Secara teknis, ada orang yang bisa bayar atau tidak?"

Tetapi juga:

apa yang terjadi selama trial state
apa yang terjadi ketika webhook state datang terlambat
bagaimana menguji dengan aman tanpa memainkan sandiwara di permukaan revenue sendiri
bagaimana memverifikasi seluruh flow tanpa menciptakan pengecualian sekali pakai yang nanti membuat sistem kurang andal

Sekarang Prova punya subscription flow yang nyata plus internal QA checkout path khusus untuk verifikasi billing yang lebih aman. Mungkin terdengar kecil. Tidak. Semakin serius sebuah produk, semakin penting punya cara untuk menguji logika komersial tanpa membohongi diri sendiri soal apa yang sudah dan belum diverifikasi.

6. Operations harus jadi bagian dari produk

Salah satu hal yang membuat Prova terasa nyata buat saya adalah saya harus memperlakukannya sebagai sistem operasional yang terpisah, bukan fitur yang diselipkan ke situs lama saya.

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

Kalimat itu tidak seksi. Tapi mungkin justru kalimat itu yang paling penting.

Karena produk tidak rusak hanya di UI. Mereka rusak di titik ketika sistem saling bertemu, ketika asumsi bocor, ketika environment melenceng, ketika seseorang berkata "nanti habis launch kita bereskan", lalu versi pasca-launch itu tidak pernah sungguh-sungguh datang.

Semakin lama saya mengerjakan Prova, semakin saya menghormati kalimat-kalimat operasional yang membosankan.

Kalau kamu ingin pressure test cepat untuk AI product-mu sendiri, tanyakan:

standard apa yang tetap fixed ketika model menjadi dinamis
retrieval apa yang menjaga output tetap grounded
eval apa yang menangkap fake personalization sebelum user yang menemukannya
edge auth, billing, atau state mana yang akan membuatmu malu besok

Kalau jawaban-jawaban itu masih kabur, produknya mungkin masih lebih demo daripada system.

Proof yang Benar-Benar Penting

Saya tidak mau bicara soal productization hanya dalam abstraksi, karena nanti terdengar lebih filosofis daripada kenyataannya.

Proof yang paling penting bukan "berapa migration yang saya tulis?"

Pertanyaannya adalah: apa yang sekarang benar-benar berfungsi untuk user sungguhan?

Di fase soft launch ini, produknya sekarang sudah bisa dengan cukup kredibel bilang:

email signup dan confirmation berfungsi
Google SSO berfungsi
optional TOTP MFA berfungsi
downloadable resources dan signed downloads berfungsi
sprint submission dan AI review berfungsi di production
Stripe checkout handoff berfungsi

Itu layer proof yang terlihat oleh buyer.

Di bawahnya masih ada system proof dari repo dan rollout:

17 Supabase migrations diterapkan lewat bootstrap schema production saat ini
4,390 knowledge-base rows di production dipublikasikan dan ditag untuk composition retrieval
38 downloadable resources dipublikasikan
tagged retrieval gate yang mengalahkan baseline tanpa tag
full 18-case composition eval suite yang lolos gate
internal QA checkout path yang lebih aman untuk verifikasi billing

Saya tidak menuliskan angka-angka ini supaya terlihat sibuk.

Yang belum saya punya adalah proof eksternal yang luas dari batch pengguna yang cukup berarti yang berkata, "ini mengubah hasil buat saya." Masih terlalu awal untuk itu, dan saya tidak mau memalsukannya.

Saya menuliskannya karena sangat mudah meremehkan arti sebenarnya dari "mengubah ide menjadi produk" kalau kamu hanya bicara dalam bahasa launch.

Yang penting bukan hitungannya sendiri.

Yang penting adalah apa yang angka-angka itu wakili:

sprint system berhenti jadi dekorasi
retrieval berhenti kabur
evaluation berhenti performatif
product state menjadi cukup durable untuk diandalkan

Pekerjaan yang tidak terlihat tetaplah pekerjaan.

Dan sering kali itulah pekerjaan yang lebih berat.

Apa yang Ini Ubah di Kepala Saya

Saya masih percaya AI tools penting. Tentu saja penting.

Codex berguna di push ini karena rasanya kompeten, hati-hati, dan metodis. Ia membantu saya bergerak melalui engineering work tanpa terlalu banyak emotional theater. Claude masih terasa lebih baik buat saya ketika pekerjaannya jadi lebih soal taste dan kreativitas.

Tapi Prova mendorong saya ke kesimpulan yang lebih penting:

Saya rasa AI bisa mempercepat implementation, tetapi tidak menghilangkan kebutuhan akan judgment tentang product boundaries, sequencing, credibility, dan operational truth.

Judgment itu sendiri tetaplah pekerjaannya.

Landing page bukan produk.

Konsep yang punya nama bukan produk.

Chat interface bukan produk.

Generated component jelas bukan produk.

Buat saya, yang membuat sesuatu mulai terasa seperti produk adalah arsitektur yang tak terlihat di sekitar pengalaman yang terlihat. Ketika pengguna sungguhan bisa masuk, membayar, maju, terblokir, pulih, submit work, dan percaya pada state yang mereka lihat, kamu sudah tidak lagi bermain-main dengan demo. Kamu sedang membuat janji.

Dan saya rasa, di titik janji itulah product building menjadi serius.

Ini Pelajaran April yang Lebih Berguna

Saya masih berutang verdict 30 hari penuh tentang Codex pada May 2, 2026, dan saya memang berniat menerbitkannya saat itu.

Post itu akan jadi tempat yang tepat untuk cost timeline, cerita soal limits, apa yang saya rindukan dari Claude, dan apa yang berubah dalam model kerja saya sehari-hari.

Tetapi Prova sudah lebih dulu mengajari saya sesuatu yang lebih tahan lama daripada sekadar tool comparison:

Bagian yang menarik dari AI product building jarang sekali demonya.

Bagian menariknya adalah titik ketika sistemmu mulai membuat janji nyata kepada pengguna, dan kamu sadar betapa banyak dari janji itu hidup di luar generated code.

Saya jauh lebih menghormati bagian itu sekarang.

Dan sejujurnya, saya rasa lebih banyak builder seharusnya membicarakan bagian itu.

Pertanyaan yang Sering Ditanyakan

Apa itu Prova?

Prova adalah program AI builder yang terstruktur untuk marketer dan advertising professionals yang ingin bergerak dari sekadar memakai AI tools menuju membangun workflow, pilot, dan operating system yang nyata. Dalam terms produk, itu berarti assessment, onboarding, sprint progression, review logic, resources, billing, auth, dan product state yang bekerja bersama, bukan satu AI chat box yang pura-pura menjadi seluruh sistem.

Apa itu composed sprint di Prova?

Composed sprint adalah sprint packet yang di-generate untuk gap nyata pada learner yang berada di luar authored catalog saat ini. Constraint terpentingnya adalah model tidak mengarang standard sendirian. Packet-nya dinamis, tetapi submission schema dan review rubric tetap datang dari authored template sprint.

Kenapa AI product building jadi lebih sulit setelah demo?

Karena begitu user sungguhan bisa signup, membayar, pulih dari error, submit work, dan percaya pada state yang mereka lihat, produk mulai membuat janji. Di titik itu, sistem-sistem tak terlihat di sekitar AI layer, seperti auth, kualitas retrieval, evals, billing, dan operations, jadi lebih penting daripada output pertama yang tampak mengesankan dalam demo.

Kalau kamu sedang membangun dengan AI sekarang, saya sungguh penasaran:

apa momen pertama ketika project-mu mulai terasa tidak nyaman karena terlalu nyata, momen ketika demo berubah menjadi janji?

Sekian dulu dari saya.

Cheers, Chandler