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 हो जाती है।

16 अप्रैल 2026 का update: जब से मैंने इस post का पहला version draft किया है, Prova पहले ही एक ज़्यादा साफ़ Operator/Builder split की तरफ़ shift हो चुकी है। मैंने main thesis को जस का तस रखा है और नीचे product-specific details update कर दिए हैं, ताकि यह अभी live चल रही चीज़ से aligned रहे।

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

अगर आपने Prova के बारे में पहले नहीं सुना: यह marketers और advertising professionals के लिए मेरा coaching product है, जिसमें workflow redesign के लिए एक Operator path और पहला useful slice ship करने के लिए एक Builder path है।

मुश्किल हिस्सा, मेरे अनुभव में, LLM से code generate कराना नहीं था। मुश्किल हिस्सा code के आसपास की सारी चीज़ें थीं।

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

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

मुझे मानना पड़ेगा, Prova का नाम तय करना easy decision था। Prova का मतलब proof या test जैसा है, जो बिल्कुल इस product के असली काम पर फिट बैठता है: लोगों को उनका work prove करने पर मजबूर करना, न कि उन्हें flatter करके builder जैसा feel कराना।

मुश्किल हिस्सा उसके बाद शुरू हुआ। जिस पल 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 अब उससे कहीं ज़्यादा opinionated product है जितना तब थी जब मैंने इस post का पहला draft लिखना शुरू किया था। Surface दो ज़्यादा साफ़ entry paths में बँट चुकी है: एक Operator path उन लोगों के लिए जो workflows redesign कर रहे हैं, और एक Builder path उन लोगों के लिए जो पहला useful slice ship करने की कोशिश कर रहे हैं। Builder side पर अब इसका मतलब है एक Build Reality Check, एक Build Brief, एक Build Plan, build के चलते हुए एक execution lane, और किसी real user को दिखाने से पहले एक launch gate।

इस साफ़ surface के नीचे, वह मुश्किल system work वही है जो मैं तब कह रहा था जब मैंने यह draft किया था। अभी भी वही है: 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 होता, और शायद सच भी नहीं। आज की सही framing अभी भी controlled launch है: billing portal और recovery flows live हैं, लेकिन खुला काम basic product plumbing से हटकर Builder path, execution lane, और launch gate को real usage में ज़्यादा honest बनाने पर shift हो गया है। मुझे असल में लगता है यही चीज़ इस 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 नहीं

मैं सिर्फ इसलिए जीत declare नहीं करना चाहता था कि UI में एक composed sprint decent दिख रही थी। इसलिए eval system को product के साथ grow करना पड़ा।

पहले sprint review eval harness थी। फिर composition ने retrieval gate add किया, एक pass/fail check, ताकि पता चले कि tagged retrieval वास्तव में untagged baseline से grounded material को improve कर रही है या नहीं। फिर full end-to-end harness: 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 करना।

Point यह था कि "personalized progression" कहीं fake personalization न बन जाए। अगर system यह कहने वाला है, "यह next sprint सच में तुम्हारे लिए है," तो उसे सिर्फ decent-looking packet से काम नहीं चल सकता। उसे evidence चाहिए:

• 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 था, मेरा मानना है।

System इसलिए बेहतर नहीं हुई क्योंकि मेरे पास एक good prompt थी। वह इसलिए बेहतर हुई क्योंकि product मेरे सामने eval harness के भीतर fail कर सकती थी, users के सामने fail होने से पहले। यह कोई एक 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, और password recovery काम करते हैं
• Google SSO काम करता है
• optional TOTP MFA काम करता है
• downloadable resources और signed downloads काम करते हैं
• sprint submission और AI review production में काम करते हैं
• Stripe checkout handoff और billing portal access काम करते हैं

यह buyer-facing proof है।

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

• composition retrieval के लिए 4,390 production knowledge-base rows publish और tag की जा चुकी हैं
• एक tagged retrieval gate जो untagged baseline को beat कर रही है
• full 18-case composition eval suite अपना gate pass कर रही है
• billing verification के लिए एक safer internal QA checkout path

जो अभी मेरे पास नहीं है, वह 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 हो जाता है। Full 30-day Codex verdict May 2, 2026 को आएगी, और वह post cost timeline, limits story, और मेरे day-to-day working model में क्या बदला—इन सब के लिए सही जगह होगी।

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

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

Landing page product नहीं है। नाम वाला concept product नहीं है। Generated component तो बिल्कुल product नहीं है।

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

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

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

Prova क्या है?

Prova अब उन marketers और advertising professionals के लिए एक structured coaching product है जो AI work में एक ज़्यादा serious रास्ता चाहते हैं। अभी इसमें दो ज़्यादा साफ़ entry paths हैं। Operator path workflow redesign, measurement, और rollout judgment के लिए है। Builder path पहला useful slice ship करने के लिए है, और अब एक Build Reality Check, एक Build Brief, एक Build Plan, एक execution lane, और एक launch gate से होकर गुज़रता है। दोनों paths के नीचे, असली product अभी भी यही है: 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