Prova को ship करने में code आसान हिस्सा निकला

Prova मुझे उस पल real लगने लगी जब product ने मुझे खुद से झूठ बोलने नहीं दिया।

एक homepage बहुत लंबे समय तक aspirational बनी रह सकती है।

एक live product नहीं।

जैसे ही लोग signup कर सकते हैं, email confirm कर सकते हैं, गलत state में land कर सकते हैं, billing तक पहुंच सकते हैं, work submit कर सकते हैं, और expect कर सकते हैं कि system को याद रहेगा क्या हुआ था, bottleneck बदल जाता है।

Product real promises करना शुरू कर देता है। और जो invisible work थी, वह अचानक बहुत visible हो जाती है।

अगर आपने मार्च और अप्रैल की शुरुआत में Claude Max से Codex पर मेरे switch वाले तीन posts पढ़े हैं, तो आप जानते होंगे कि वह experiment अभी भी चल रहा है। मैंने पहले ही May 2, 2026 के लिए एक proper follow-up का वादा किया है, और मैं वह वादा निभाने वाला हूँ। यह वह post नहीं है।

लेकिन Prova ने मुझे उससे पहले एक और ज़्यादा useful realization दे दी:

जैसे ही कोई चीज़ सिर्फ एक named idea से बढ़कर एक real product बनना शुरू करती है, bottleneck बदल जाता है।

कम से कम, इस build में मुझे यही महसूस हुआ।

मुश्किल हिस्सा LLM से code generate कराना नहीं था।

मुश्किल हिस्सा, कम से कम इस push में, code के आसपास की सारी चीज़ें थीं।

अगर आप अभी AI के साथ कुछ बना रहे हैं, खासकर ऐसा कुछ जिसमें real users, real money, या real product state शामिल है, तो मुझे लगता है कि यही वह हिस्सा है जिसके बारे में लगभग कोई पहले से नहीं बताता।

ज़्यादा useful lesson यह है कि जब product demo से आगे बढ़ जाता है, तब वास्तव में कौन-सी चीज़ें मायने रखने लगती हैं।

नाम रखना आसान हिस्सा था

मुझे मानना पड़ेगा, Prova का नाम तय करना पूरे process के आसान decisions में से एक था।

नाम इसलिए क्लिक किया क्योंकि वह product पर सच में फिट बैठता था।

Prova का मतलब proof या test जैसा है। और वही इस product का असली काम है। यह किसी को flatter करने या उन्हें जल्दी builder जैसा feel कराने के लिए नहीं है। यह उन्हें अपना काम prove करने के लिए है। नाम अच्छा है, useful है, searchable है। दूसरे शब्दों में, वही easy part था।

मुश्किल हिस्सा उसके बाद शुरू हुआ। क्योंकि जिस पल Prova सिर्फ नाम और landing page रहना बंद हुई, उसी पल उसने उन सब unglamorous चीज़ों की demand शुरू कर दी जो real products हमेशा करते हैं:

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

इसने AI tools और product building दोनों को लेकर मेरी सोच बदल दी।

Prova को वास्तव में क्या बनना पड़ा

Prova अब marketers और advertising professionals के लिए एक structured AI builder program है, जो AI tools इस्तेमाल करने से आगे बढ़कर real workflows, pilots और operating systems बनाना चाहते हैं। Practical terms में इसका मतलब था assessment और onboarding, chat-first की जगह sprint-first product, review-driven progression, durable product state, और ऐसा mentor layer जो generic AI chat box से ज़्यादा current sprint के आसपास office hours जैसा behave करे।

साफ़ कहूँ तो, मैं यह नहीं कह रहा कि Prova "done" है। मैं चाहता तो यही कि ऐसा कह दूँ और move on कर जाऊँ, लेकिन वह थोड़ा ज़्यादा convenient होता, और शायद सच भी नहीं। आज की honest framing soft launch है: core production system live है और काम कर रहा है, लेकिन launch-readiness work अभी भी बाकी है, जिसमें billing portal return-path cleanup और ज़्यादा complete MFA automation coverage शामिल हैं। मेरी नज़र में यही चीज़ इस lesson को और useful बनाती है। Real world का product building ऐसा ही दिखता है। पूरा नहीं हुआ। Fake भी नहीं। बस इतना real कि अगली mistake की cost होगी।

वह काम जिसे मैं बस generate नहीं कर सका

किसी भी AI product का सबसे आसान version लगभग हमेशा उसका demo version होता है।

उसे जल्दी से alive जैसा दिखाया जा सकता है:

एक homepage
एक chat box
कुछ slick screenshots
एक persuasive product sentence

Launch teaser के लिए वह useful है।

लेकिन real work कहाँ है, यह समझने के लिए बहुत useful नहीं।

मेरे लिए, real work छह जगहों पर सामने आई।

1. Sprint system को pretending बंद करनी पड़ी

मैं नहीं चाहता था कि Prova ऐसा product बने जो landing page पर structured दिखे, लेकिन अंदर जाते ही generic हो जाए।

Fixed authored sprints तब तक useful थीं, जब तक वे नहीं रहीं।

असल problem तब सामने आई जब learner एक sprint pass कर रहा था, लेकिन उसका अगला real gap catalog के अगले authored sprint से match नहीं कर रहा था।

Lazy answer कुछ ऐसी होती:

"Model को next sprint invent करने दो: title, rubric, review criteria, सब कुछ।"

मुझे उस approach पर भरोसा नहीं था।

इसलिए system को उससे ज़्यादा strict होना पड़ा।

अब reviewer फिर भी canonical next sprint recommend कर सकता है जब authored path सही हो। वह adaptive detour भी assign कर सकता है, यानी ऐसा temporary sprint जो learner को foundation gap ठीक करने में मदद करे और फिर main path पर वापस भेज दे। और जब अगला real gap authored catalog के बाहर हो, तब वह composed sprint request कर सकता है।

Blog post में यह छोटा लगता है।

Product में यह बिल्कुल छोटा नहीं है।

क्योंकि composed sprint सिर्फ "dynamic text" नहीं है।

उसे placeholder sprint create करना होता है, assignment persist करना होता है, canonical roadmap की return path बचानी होती है, sprint packet fill करना होता है, और फिर बाकी system को उसे real product state की तरह treat करने देना होता है।

जिस constraint ने इसे trustworthy बनाया, वह काफी simple थी:

model standard invent नहीं कर सकता।

Composed sprint सिर्फ packet भरता है: title, summary, context, assignment, example।

Submission schema और review rubric authored template sprint से ही आते हैं।

यही पूरे build की सबसे बड़ी lessons में से एक थी।

अगर आप चाहते हैं कि कुछ dynamic होते हुए भी trustworthy रहे, तो contract fixed रखिए और model को उसी contract के भीतर operate करने दीजिए।

यही वह जगह भी थी जहाँ Codex ने मेरी बहुत मदद की। किसी flashy तरीके से नहीं, जैसे "देखो, इसने क्या generate किया।" बल्कि कहीं ज़्यादा useful तरीके से: migrations, router logic, placeholder lifecycle, request state, integration tests, और वह सारा boring contract work जो एक dynamic product को कम fake बनाती है।

और सच कहूँ तो, lazy version ने मुझे थोड़ी देर के लिए tempt भी किया। Model को clever होने दो। System को magical लगने दो। बाद में साफ़ कर लेंगे। वह idea तब तक अच्छी लगती है जब तक आप खुद को किसी paying user को bad sprint assignment समझाते हुए imagine नहीं करते।

2. Retrieval को curricular बनना पड़ा, सिर्फ semantic नहीं

जैसे ही मैंने system को sprints compose करने दिए, retrieval quality backend detail भर नहीं रही।

वह curriculum quality बन गई।

अगर product tooling, measurement, या competitive intelligence पर sprint compose करने वाला है, तो वह knowledge base से बस "कुछ related" chunks खींचकर packet के coherent लगने की उम्मीद नहीं कर सकता।

Knowledge base को खुद ज़्यादा smart बनना पड़ा।

हमने उसे real corpus से rebuild किया: blog posts, course modules, transcripts, companions, templates, और deep-dive resources।

फिर source के type के हिसाब से chunking बदली।

Narrative blog posts बड़े रह सकते थे।

Instructional modules को heading-first chunks चाहिए थे।

Templates और reference assets को ऐसे structured chunking की ज़रूरत थी जो tables, checklists, slide references, और quick-reference sections को preserve करे, उन्हें generic paragraphs में flatten न कर दे।

उसके बाद tagging important हो गया।

सिर्फ "यह किस बारे में है?" नहीं, बल्कि:

यह chunk किस तरह का है
कौन-से topic tags फिट बैठते हैं
यह किस audience के लिए है
यह किस difficulty level का है

इससे retrieval "nearest vector wins" से बदलकर curricular matching जैसा हो गया।

Product अब ऐसे पूछ सकता था:

"मुझे इस topic, इस audience, और इस level के लिए grounded material दो।"

यह किसी demo पर बस RAG चिपका देने से कहीं ज़्यादा serious system है।

3. Evals को पूरी pipeline test करनी पड़ी, सिर्फ model नहीं

यह शायद सबसे important lesson थी।

मैं सिर्फ इसलिए जीत declare नहीं करना चाहता था कि UI में एक composed sprint decent दिख रही थी।

इसलिए eval system को product के साथ grow करना पड़ा।

पहले sprint review eval harness थी।

फिर composition ने retrieval gate add किया, basically एक pass/fail check, ताकि पता चले कि tagged retrieval वास्तव में untagged baseline से grounded material को improve कर रही है या नहीं।

फिर composition ने full end-to-end harness add किया:

sprint packet compose करना
schema-valid synthetic submissions generate करना
real reviewer को उन submissions पर run करना
grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality, और authored work से comparison के आधार पर result judge करना

यही real learning loop थी।

Plain Hindi में कहूँ तो point यह था कि "personalized progression" कहीं fake personalization न बन जाए। अगर system यह कहने वाला है, "यह next sprint सच में तुम्हारे लिए है," तो उसे सिर्फ decent-looking packet से काम नहीं चल सकता। उसे evidence चाहिए कि sprint grounded है, level-appropriate है, और authored curriculum जैसे ही standards पर reviewable भी है।

यह सवाल नहीं था कि "model JSON लौटा रहा है या नहीं?"

बल्कि:

packet grounded रही या नहीं
track framing ने सच में work product बदला या नहीं
level 2 और level 5 material तौर पर अलग लगे या नहीं
reviewer ने सही pass/revise call किया या नहीं
composed sprint अब भी curriculum का हिस्सा लगी या नहीं

इस loop ने real problems expose कीं।

Weak revise submissions जो फिर भी बहुत strong थीं।

Audience framing जो tracks के बीच collapse हो जाती थी।

Measurement packets जो पढ़ने में ठीक लगती थीं, लेकिन अलग-अलग learners के लिए अलग trust questions का जवाब नहीं दे रही थीं।

मेरे लिए सबसे humbling moments में से एक यह था कि मुझे समझ आया कि कितनी बार कोई चीज़ UI में "काफी अच्छी" दिख सकती है, और फिर भी पहली strict question पर fail हो सकती है। Packet smooth पढ़ी जा सकती थी और फिर भी generic रह सकती थी। Revise case plausible लग सकती थी और फिर भी बहुत आसान हो सकती थी। मेरे ego के लिए यह useful था, मेरा मानना है।

और इसी वजह से मुझे यह हिस्सा इतना important लगता है।

System इसलिए बेहतर नहीं हुई क्योंकि मेरे पास एक good prompt थी।

वह इसलिए बेहतर हुई क्योंकि product मेरे सामने eval harness के भीतर fail कर सकती थी, users के सामने 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

यह sequence matter करता है।

यह कोई एक miracle नहीं था। यह controlled loop थी।

4. Trust surfaces को सच में real होना पड़ा

यहीं real products demos से अलग होने लगते हैं।

कोई भी इस बात की परवाह नहीं करता कि आपकी AI layer कितनी elegant है अगर:

email confirmation टूटती है
Google sign-in flaky है
user auth loop में फंस जाता है
abuse controls missing हैं
account hardening afterthought जैसा feel होता है

Prova के लिए, credibility layer में आखिरकार यह सब शामिल हुआ:

email confirmation जो लोगों को सही product flow में वापस लाती है
Google SSO
optional app-based two-factor auth (TOTP MFA)
auth और assessment पर Turnstile protection

यह वही तरह का काम है जिसके बारे में लोग brag नहीं करते, क्योंकि यह operational और boring सुनाई देता है।

मुझे लगता है यह गलती है।

Operational और boring वाली जगहों पर ही products trust कमाते हैं या चुपचाप खो देते हैं।

5. Billing को testable होना पड़ा, सिर्फ imaginable नहीं

मैं उन product builders को लेकर increasingly skeptical होता जा रहा हूँ जो monetization की बात ऐसे करते हैं जैसे वह सिर्फ एक Stripe screenshot दूर हो solved होने से।

Billing बहुत जल्दी real हो जाती है।

यह सिर्फ इतना नहीं है:

"क्या technically कोई pay कर सकता है?"

यह भी है:

trial state के दौरान क्या होता है
webhook state late आए तो क्या होता है
अपनी ही revenue surface पर theater किए बिना safely test कैसे करें
पूरे flow को verify कैसे करें बिना ऐसे one-off exceptions invent किए जो बाद में system को कम reliable बना दें

अब Prova के पास real subscription flow है, और billing verification के लिए internal QA checkout path भी। यह सुनने में छोटा लग सकता है। है नहीं। Product जितनी serious होती जाती है, उतना ही ज़रूरी होता है कि आपके पास commercial logic को test करने के तरीके हों, बिना खुद से झूठ बोले कि क्या verify हुआ है और क्या नहीं।

6. Operations को product का हिस्सा बनना पड़ा

जो चीज़ें Prova को मेरे लिए real बनाती थीं, उनमें से एक यह थी कि मुझे उसे एक अलग operational system की तरह treat करना पड़ा, न कि existing site के अंदर छिपा हुआ feature।

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

यह sentence sexy नहीं है। लेकिन शायद यही sentence सबसे ज़्यादा important है।

क्योंकि products सिर्फ UI layer पर नहीं टूटते। वे वहाँ टूटते हैं जहाँ systems आपस में छूते हैं, जहाँ assumptions leak करती हैं, जहाँ environments drift करते हैं, जहाँ कोई कहता है "launch के बाद ठीक कर लेंगे," और फिर after-launch version असल में कभी आती ही नहीं।

मैंने जितना Prova पर काम किया, उतना ही boring operational sentences के लिए respect बढ़ता गया।

अगर आप अपने AI product का fast pressure test करना चाहते हैं, तो पूछिए:

कौन-सा standard fixed रहता है जब model dynamic हो जाती है
कौन-सा retrieval output को grounded रखता है
कौन-सा eval fake personalization को user से पहले पकड़ लेता है
कौन-सा auth, billing, या state edge आपको कल शर्मिंदा कर देगा

अगर इन सवालों के जवाब अभी भी fuzzy हैं, तो product शायद अभी भी system से ज़्यादा demo है।

वह proof जो सच में matter करती है

मैं productization की बात सिर्फ abstraction में नहीं करना चाहता, क्योंकि तब वह असलियत से ज़्यादा philosophical लगने लगती है।

सबसे important proof यह नहीं है: "मैंने कितनी migrations लिखीं?"

असल सवाल यह है: आज एक real user के लिए क्या सच में काम करता है?

इस soft-launch phase में, product अब यह credibly कह सकती है:

email signup और confirmation काम करती हैं
Google SSO काम करता है
optional TOTP MFA काम करता है
downloadable resources और signed downloads काम करते हैं
sprint submission और AI review production में काम करते हैं
Stripe checkout handoff काम करता है

यह buyer-facing proof है।

इसके नीचे repo और rollout work से system proof भी है:

current production schema bootstrap तक 17 Supabase migrations लागू हो चुकी हैं
composition retrieval के लिए 4,390 production knowledge-base rows publish और tag की जा चुकी हैं
38 downloadable resources publish हो चुकी हैं
tagged retrieval gate ने untagged baseline को beat किया है
full 18-case composition eval suite अपना gate pass कर चुकी है
billing verification के लिए safer internal QA checkout path मौजूद है

मैं यह numbers इसलिए नहीं बता रहा कि busy लगूँ।

जो अभी मेरे पास नहीं है, वह meaningful batch of users से broad external proof है जो कहे: "इसने outcomes बदल दिए।" उसके लिए अभी बहुत जल्दी है, और मैं उसे fake नहीं करना चाहता।

मैं इन्हें इसलिए लिख रहा हूँ क्योंकि "एक idea को product में बदलना" असल में क्या मतलब रखता है, इसे underestimate करना बहुत आसान है, अगर आप सिर्फ launch language में बात करते हैं।

Important चीज़ numbers नहीं हैं।

Important यह है कि वे represent क्या करती हैं:

sprint system decorative रहना बंद कर चुकी है
retrieval fuzzy रहना बंद कर चुकी है
evaluation performative रहना बंद कर चुकी है
product state इतना durable हो चुका है कि उस पर भरोसा किया जा सके

Invisible work फिर भी work ही रहती है।

और अक्सर वही ज़्यादा मुश्किल work होती है।

इसने मेरे दिमाग में क्या बदला

मैं अब भी मानता हूँ कि AI tools matter करती हैं। बिल्कुल करती हैं।

Codex इस push में useful रही क्योंकि वह competent, careful, और methodical लगी। उसने मुझे engineering work में आगे बढ़ने में मदद की, बिना बहुत emotional theater के। Claude मुझे अब भी तब better लगती है जब काम ज़्यादा taste-heavy और creative हो जाता है।

लेकिन Prova मुझे एक और ज़्यादा important conclusion तक ले गई:

मेरे हिसाब से AI implementation को accelerate कर सकती है, लेकिन product boundaries, sequencing, credibility, और operational truth को लेकर judgment की ज़रूरत खत्म नहीं करती।

वही judgment अभी भी असली काम है।

Landing page product नहीं है।

नाम वाला concept product नहीं है।

Chat interface product नहीं है।

Generated component तो बिल्कुल product नहीं है।

मेरे लिए, कोई चीज़ तब product लगने लगती है जब visible experience के आसपास invisible architecture खड़ी हो जाती है। जिस पल real users अंदर आ सकती हैं, pay कर सकती हैं, progress कर सकती हैं, block हो सकती हैं, recover कर सकती हैं, work submit कर सकती हैं, और जो state वे देख रही हैं उस पर trust कर सकती हैं, उसी पल आप demo से आगे बढ़ चुके होते हैं। आप promises कर रहे होते हैं।

और मेरे हिसाब से product building उसी पल serious होती है।

मेरे लिए यही ज़्यादा useful April lesson है

मैं अभी भी May 2, 2026 को full 30-day Codex verdict देने वाला हूँ।

वह post cost timeline, limits story, मुझे Claude में क्या miss हुआ, और मेरे day-to-day working model में क्या बदला—इन सब के लिए सही जगह होगी।

लेकिन Prova मुझे अभी से एक ऐसी चीज़ सिखा चुकी है जो tool comparison से ज़्यादा टिकाऊ है:

AI product building का interesting हिस्सा शायद ही कभी demo होता है।

Interesting हिस्सा वह point है जहाँ आपका system users से real promises करना शुरू करता है, और आप notice करते हैं कि उन promises का कितना हिस्सा generated code के बाहर रहता है।

अब मुझे उस हिस्से के लिए कहीं ज़्यादा respect है।

और honestly, मुझे लगता है कि ज़्यादा builders को इसी हिस्से पर बात करनी चाहिए।

अक्सर पूछे जाने वाले सवाल

Prova क्या है?

Prova marketers और advertising professionals के लिए structured AI builder program है, जो AI tools इस्तेमाल करने से आगे बढ़कर real workflows, pilots, और operating systems बनाना चाहते हैं। Product terms में यह assessment, onboarding, sprint progression, review logic, resources, billing, auth, और product state का साथ मिलकर काम करना है, न कि एक AI chat box जो पूरा system होने का नाटक करे।

Prova में composed sprint क्या है?

Composed sprint वह sprint packet है जो learner के real gap के लिए generate की जाती है, जब वह gap current authored catalog के बाहर होती है। सबसे important constraint यह है कि model standard खुद invent नहीं करती। Packet dynamic है, लेकिन submission schema और review rubric authored template sprint से ही आती हैं।

Demo के बाद AI product building ज़्यादा मुश्किल क्यों हो जाती है?

क्योंकि जैसे ही real users signup कर सकती हैं, pay कर सकती हैं, errors से recover कर सकती हैं, work submit कर सकती हैं, और अपने सामने दिख रही state पर trust कर सकती हैं, product promises करना शुरू कर देती है। उस point के बाद AI layer के आसपास की invisible systems—जैसे auth, retrieval quality, evals, billing, और operations—demo के impressive first output से ज़्यादा matter करती हैं।

अगर आप अभी AI के साथ build कर रहे हैं, तो मैं genuinely curious हूँ:

आपके project में वह पहला moment कौन-सा था जब उसने uncomfortable तरह से real feel करना शुरू किया—वह पल जब demo, promise बन गई?

फिलहाल इतना ही।

Cheers, Chandler