AI प्रोटोटाइप को प्रोडक्शन तक कैसे ले जाएं

AI प्रोटोटाइप को प्रोडक्शन तक ले जाने के लिए आप उस खाई को पाटते हैं जो “मेरे आज़माने पर यह काम करता है” और “जब दूसरे लोग इस्तेमाल करें तब भी काम करता रहता है” के बीच होती है। व्यवहार में इसके पांच काम हैं: हर बदलाव के बाद मुख्य फ़्लो टेस्ट करना, तय करना कि कौन क्या देख और बदल सकता है, उपयोगकर्ता बताने से पहले ही एरर की जानकारी पाना, डेटा का बैकअप लेना और साबित करना कि उसे रिस्टोर किया जा सकता है, और फ़ोन पर भी ऐप को काफ़ी तेज़ रखना। इनमें से कुछ भी पूरी तरह दोबारा लिखने की ज़रूरत नहीं है — यह एक चेकलिस्ट है जिस पर आप उसी AI के साथ काम करते हैं जिसने प्रोटोटाइप बनाया था।

प्रोटोटाइप बनाम प्रोडक्शन: असल में क्या बदलता है

प्रोटोटाइप का एक ही सावधान यूज़र होता है: आप। आप जानते हैं कि कौन से बटन दबाने हैं, आप समझदार इनपुट डालते हैं, और कुछ टूटे तो बस AI से ठीक करने को कहते हैं। प्रोडक्शन में बहुत सारे लापरवाह यूज़र होते हैं, कुछ जिज्ञासु, और कभी-कभी एक दुश्मन भी। कोड को “एंटरप्राइज़” बनने की ज़रूरत नहीं है; उसे उन परिस्थितियों को संभालना है जो प्रोटोटाइप में कभी सामने नहीं आतीं।

इस गाइड के बाकी हिस्से में इस तालिका की हर पंक्ति पर बात है।

चरण 1: दायरा तय करें और मुख्य फ़्लो लिखें

कुछ भी मज़बूत बनाने से पहले तय करें कि पहला संस्करण क्या है। वे तीन से छह फ़्लो लिखें जो सबसे ज़रूरी हैं — जैसे “साइन अप करें, एक प्रोजेक्ट बनाएं, एक टीममेट को बुलाएं, पेमेंट करें”। ये आपकी टेस्ट स्क्रिप्ट, आपके मॉनिटरिंग लक्ष्य और हर बदलाव के बाद जांचने वाली चीज़ें बन जाते हैं।

सूची में न होने वाली हर चीज़ या तो हटा दें या साफ़ तौर पर बीटा लिखें। चौदह फ़्लो को भरोसेमंद बनाने से चार फ़्लो को बनाना कहीं आसान है।

चरण 2: अनजान व्यक्ति की तरह टेस्ट करें, फिर उसे दोहराने लायक बनाएं

AI बिल्डर “हैप्पी पाथ” पर काम करने वाला कोड बनाने में अच्छे हैं। प्रोडक्शन की समस्याएं गलत रास्तों पर होती हैं। हर मुख्य फ़्लो को इन तरीकों से टेस्ट करें:

• गलत इनपुट: खाली ज़रूरी फ़ील्ड, 5,000 अक्षरों का नाम, बिना @ वाला ईमेल, ऋणात्मक मात्रा, बीती हुई तारीख।
• रिफ़्रेश और बैक बटन: चेकआउट के बीच में पेज रिफ़्रेश करें; फ़ॉर्म सबमिट करने के बाद बैक दबाएं। क्या कुछ दो बार बन गया?
• दो टैब, दो यूज़र: दो अलग खातों से लॉग इन करें और URL में ID बदलकर एक-दूसरे के पेज खोलने की कोशिश करें।
• धीमा और छोटा: फ़ोन जैसी स्क्रीन और धीमा कनेक्शन (ब्राउज़र डेवलपर टूल इसे सिमुलेट कर सकते हैं)।
• खाली स्थितियां: बिल्कुल नया खाता जिसमें कोई डेटा नहीं। प्रोटोटाइप अक्सर सैंपल डेटा से बनते हैं और उसके बिना टूटे दिखते हैं।

फिर जांच को दोहराने योग्य बनाएं। कम से कम, एक लिखित चेकलिस्ट रखें और हर रिलीज़ से पहले उसे चलाएं। बेहतर यह है कि AI से उन फ़्लो के लिए ऑटोमेटेड टेस्ट लिखवाएं जो सबसे ज़रूरी हैं:

इन फ़्लो के लिए ऑटोमेटेड एंड-टू-एंड टेस्ट लिखो: ईमेल से साइन अप, एक प्रोजेक्ट बनाना, एक दूसरा यूज़र बुलाना, और Stripe टेस्ट मोड में चेकआउट पूरा करना। साथ ही टेस्ट लिखो जो पुष्टि करें कि यूज़र URL बदलकर किसी और का प्रोजेक्ट न देख सके और न बदल सके।

वे टेस्ट जो साबित करते हैं कि यूज़र कुछ नहीं कर सकता, वही वे चीज़ें हैं जो प्रोटोटाइप में सबसे अधिक छूटती हैं।

चरण 3: सुरक्षा की बुनियादी बातें जो प्रोटोटाइप छोड़ देते हैं

AI से बने ऐप की ज़्यादातर सुरक्षा समस्याएं अनोखी नहीं होतीं। वे गायब जांचें होती हैं। यह सूची देखें, और AI से बने ऐप के लिए पूरी सुरक्षा चेकलिस्ट भी देखें:

• सर्वर पर अनुमति जांच। सिर्फ़ बटन छिपाना सुरक्षा नहीं है। हर अनुरोध जो डेटा पढ़ता या बदलता है, उसे सर्वर पर जांचना होगा कि लॉगिन यूज़र को अनुमति है। अगर आपका ऐप डेटाबेस के रो-लेवल नियम इस्तेमाल करता है, तो जांचें कि वे चालू हैं और टेस्ट हुए हैं।
• सीक्रेट ब्राउज़र से बाहर। पेमेंट, ईमेल या AI प्रदाताओं की API कुंजियां सर्वर-साइड एनवायरनमेंट वेरिएबल में रहनी चाहिए, कभी फ्रंट-एंड कोड में नहीं। अगर पक्का नहीं कि इसका मतलब क्या है, तो एनवायरनमेंट वेरिएबल और सीक्रेट क्या हैं पढ़ें।
• सर्वर पर वैलिडेशन। ब्राउज़र को बायपास किया जा सकता है, इसलिए हर ज़रूरी जांच सर्वर पर दोहराएं।
• लॉगिन सही तरीके से। पासवर्ड स्टोर करने के लिए अपना कोड लिखने के बजाय अच्छी तरह टेस्ट की गई ऑथ लाइब्रेरी या सेवा इस्तेमाल करें। अपने ऐप में लॉगिन कैसे जोड़ें में विकल्प समझाए गए हैं।
• रेट लिमिट लॉगिन, साइन अप, पासवर्ड रीसेट और उन सभी चीज़ों पर जो ईमेल भेजती हैं या पैसे वाला API कॉल करती हैं।
• मैत्रीपूर्ण एरर। यूज़र को “कुछ गड़बड़ हो गई” दिखे; विवरण आपके लॉग में जाएं, स्क्रीन पर नहीं।
• लीक हुई हर चीज़ बदलें। अगर कोई लाइव कुंजी कभी चैट, कमिट या स्क्रीनशॉट में चिपकाई गई थी, तो उसे प्रदाता के पास बदल दें।

एक प्रॉम्प्ट जो एक साथ काफ़ी कुछ कवर करता है:

इस ऐप की प्रोडक्शन सुरक्षा जांचो। देखो कि हर API रूट यह सत्यापित करता है कि लॉगिन यूज़र उस रिकॉर्ड का मालिक है जिसे वह पढ़ या बदल रहा है, कि कोई सीक्रेट कुंजी ब्राउज़र को नहीं भेजी जा रही, कि इनपुट सर्वर पर वैलिडेट होते हैं, और कि लॉगिन व पासवर्ड रीसेट पर रेट लिमिट है। कुछ भी बदलने से पहले पाई गई समस्याओं की सूची दो।

पहले सूची मांगने से आप समस्याएं देख सकते हैं और क्रम तय कर सकते हैं, बजाय एक बड़े बदलाव के।

चरण 4: पता रखें कि कब टूटता है — लॉगिंग और मॉनिटरिंग

प्रीव्यू में एरर आपको दिखते हैं जैसे ही वे होते हैं। प्रोडक्शन में ऐप को आपको बताना होगा। तीन परतें हैं, सबसे सस्ती से सबसे उपयोगी तक:

1. सर्वर लॉग। सुनिश्चित करें कि एरर पर्याप्त संदर्भ के साथ लॉग होते हैं ताकि उन्हें दोहराया जा सके: कौन सा रूट, कौन सा यूज़र ID (पासवर्ड या कार्ड नहीं), इनपुट का आकार। अगर ऐप सिर्फ़ कंसोल में प्रिंट करता है, तो AI से स्ट्रक्चर्ड लॉगिंग जोड़ने को कहें।
2. एरर ट्रैकिंग। Sentry जैसी या मिलती-जुलती सेवा फ्रंट-एंड और बैक-एंड दोनों के अपवाद पकड़ती है, उन्हें समूहित करती है और आपको ईमेल भेजती है। छोटे ऐप के लिए इन सेवाओं के फ़्री टियर अक्सर काफ़ी होते हैं; मौजूदा सीमाएं उनकी साइट पर जांचें।
3. अपटाइम जांच। एक बाहरी सेवा जो हर कुछ मिनट में आपका होम पेज और एक मुख्य API रूट लोड करती है और विफल होने पर अलर्ट देती है। यह उन समस्याओं को पकड़ती है जो ऐप को लॉग करने से ही रोक देती हैं।

एक और आदत जोड़ें: हर रिलीज़ के बाद लाइव ऐप खोलें और प्रीव्यू पर नहीं, असली URL पर अपना मुख्य फ़्लो चेकलिस्ट से चलाएं।

चरण 5: बैकअप और वापस लौटने का तरीका

दो अलग चीज़ों की सुरक्षा करनी होती है, और इन्हें आसानी से एक-दूसरे में मिलाया जा सकता है।

• कोड। प्रोजेक्ट को वर्शन कंट्रोल में रखें ताकि कोई भी बदलाव वापस लिया जा सके। कई AI बिल्डर आपकी फ़ाइलों के चेकपॉइंट रखते हैं; Git रिपॉज़िटरी से सिंक करने से बिल्डर के बाहर भी एक कॉपी मिल जाती है।
• डेटा। कोड चेकपॉइंट पर लौटने से डेटाबेस वापस नहीं आता। एक खराब माइग्रेशन या गलत डिलीट बटन ऐसी पंक्तियां मिटा सकता है जो कोई कोड चेकपॉइंट वापस नहीं लाएगा।

डेटा के लिए नियमित बैकअप सेट करें जो ऐप की अपनी होस्टिंग के अलावा किसी और जगह रखे जाएं — Postgres डेटाबेस के लिए आम तरीका है एक शेड्यूल्ड pg_dump को अलग स्टोरेज में भेजना, और कई मैनेज्ड डेटाबेस होस्ट ऑटोमैटिक बैकअप या पॉइंट-इन-टाइम रिकवरी देते हैं। फिर वह कदम उठाएं जो ज़्यादातर लोग छोड़ देते हैं: एक बैकअप को अलग स्क्रैच डेटाबेस में रिस्टोर करें और जांचें कि डेटा वहां है।

साथ ही AI से विनाशकारी कार्रवाइयों को सुरक्षित बनाने को कहें: डिलीट के लिए पुष्टि कदम, और उन चीज़ों के लिए “सॉफ़्ट डिलीट” (रो को हटाने के बजाय डिलीटेड चिह्नित करना) जो यूज़र बाद में वापस चाहें।

चरण 6: फ़ोन पर भी टिकने वाली परफ़ॉर्मेंस

प्रोटोटाइप तेज़ लगते हैं क्योंकि आप अकेले यूज़र हैं और डेटा बहुत छोटा है। लॉन्च से पहले:

• असली आकार के डेटा से लोड करें। AI से कुछ हज़ार रो सीड करवाएं और देखें कि कौन से पेज धीमे होते हैं। लिस्ट को आम तौर पर पेजिनेशन चाहिए, और डेटाबेस को उन कॉलम पर इंडेक्स चाहिए जिन पर आप फ़िल्टर या सॉर्ट करते हैं।
• तस्वीरें छोटी करें। बड़ी तस्वीरें पेज धीमा होने का सबसे आम कारण हैं। साइज़ घटी हुई, कंप्रेस्ड तस्वीरें और फ़ोल्ड के नीचे लेज़ी लोडिंग मांगें।
• मापें। लाइव URL पर Chrome के डेव टूल में मोबाइल मोड में Lighthouse चलाएं। Google के Core Web Vitals एक अच्छा लक्ष्य हैं: Largest Contentful Paint 2.5 सेकंड के अंदर, Interaction to Next Paint 200 ms या उससे कम, और Cumulative Layout Shift 0.1 या उससे कम।
• “जागने” में देरी पर नज़र रखें। निष्क्रिय होने पर सो जाने वाली होस्टिंग पैसे बचाती है, पर शांत अवधि के बाद पहली विज़िट धीमी होती है। नए ऐप के लिए यह अक्सर ठीक समझौता है; बस जानें कि यह हो रहा है।

प्रोजेक्ट्स पेज 5,000 रो के साथ धीमा है। सर्वर-साइड पेजिनेशन (प्रति पेज 25) जोड़ें, जिन कॉलम पर हम फ़िल्टर और सॉर्ट करते हैं उन पर डेटाबेस इंडेक्स जोड़ें, और अगला पेज लोड होते समय लोडिंग स्टेट दिखाएं।

चरण 7: ऑपरेशन की बुनियादी बातें

कुछ छोटी चीज़ें एक शौकिया ऐप को उस ऐप से अलग करती हैं जिस पर लोग भरोसा करते हैं:

• HTTPS वाला कस्टम डोमेन। कस्टम डोमेन कैसे जोड़ें देखें।
• ट्रांज़ैक्शनल ईमेल एक सत्यापित डोमेन से, साइन-अप कन्फ़र्मेशन और पासवर्ड रीसेट के लिए — अपने ऐप से ईमेल कैसे भेजें में समझाया गया है।
• प्राइवेसी पॉलिसी और शर्तें जो बताएं कि आप असल में क्या इकट्ठा करते हैं। जो अनुपालन दावे आपने अर्जित नहीं किए हैं, उन्हें कॉपी न करें।
• सहायता का रास्ता — कम से कम एक मॉनिटर किया हुआ ईमेल पता।
• टेस्ट और लाइव कुंजियां अलग-अलग पेमेंट और ईमेल के लिए, और यह साफ़ नोट कि कौन सा एनवायरनमेंट कौन सी कुंजी इस्तेमाल करता है।

चरण 8: साफ़ हैंडओवर

देर-सबेर ऐप पर कोई और काम करेगा: फ़्रीलांसर, नया को-फ़ाउंडर, या छह महीने बाद आप खुद। इसे आसान बनाएं:

• एक README जो बताए कि इसे कैसे चलाना है, किन एनवायरनमेंट वेरिएबल की ज़रूरत है (सिर्फ़ नाम, कभी मान नहीं), और इसे कैसे डिप्लॉय करना है।
• मुख्य फ़्लो की चेकलिस्ट और ऑटोमेटेड टेस्ट।
• एक छोटा आर्किटेक्चर नोट: फ्रंट एंड, बैक एंड, डेटाबेस, थर्ड-पार्टी सेवाएं, और हर एक कहां होस्ट है।
• एक्सेस सूची: कौन डोमेन, होस्टिंग, डेटाबेस, पेमेंट और ईमेल खातों का एडमिन है। ये खाते व्यक्तिगत ईमेल के बजाय बिज़नेस ईमेल के तहत रखें।
• कोड Git में, आदर्श रूप से एक ऐसे रिपॉज़िटरी से सिंक किया हुआ जो आपका अपना हो। अगर बाद में होस्टिंग बदलने की संभावना है, तो AI से बने ऐप को एक्सपोर्ट करके खुद होस्ट कैसे करें पढ़ें।

इसका ज़्यादातर हिस्सा AI आपके लिए ड्राफ्ट कर सकता है:

इस प्रोजेक्ट के लिए एक README लिखो उस डेवलपर के लिए जिसने इसे कभी नहीं देखा: ऐप क्या करता है, टेक स्टैक, इसे लोकल पर कैसे चलाएं, हर एनवायरनमेंट वेरिएबल जो यह पढ़ता है (सिर्फ़ नाम और उद्देश्य), डेटाबेस स्कीमा कैसे व्यवस्थित है, और इसे कैसे डिप्लॉय करें।

प्रोडक्शन-रेडीनेस चेकलिस्ट

• मुख्य फ़्लो लिखे और टेस्ट किए गए, जिसमें “किसी और का डेटा एक्सेस नहीं कर सकते” भी शामिल है
• हर डेटा रूट पर सर्वर-साइड अनुमति और वैलिडेशन
• फ्रंट-एंड कोड में कोई सीक्रेट कुंजी नहीं; लीक हुई कुंजियां बदली गईं
• ऑथ और पैसे लगने वाली हर चीज़ पर रेट लिमिट
• एरर ट्रैकिंग और अपटाइम अलर्ट उस इनबॉक्स की ओर जिसे आप पढ़ते हैं
• ऐप की होस्टिंग के बाहर डेटाबेस बैकअप, और एक सफल टेस्ट रिस्टोर
• असली आकार के डेटा के साथ पेजिनेशन और इंडेक्स जांचे गए
• कस्टम डोमेन, सत्यापित ईमेल भेजने वाला डोमेन, प्राइवेसी पॉलिसी
• अगले व्यक्ति के लिए README और एक्सेस सूची

Mythex के साथ यह काम

अगर आपने प्रोटोटाइप Mythex में बनाया है, तो इनमें से ज़्यादातर चरण उसी प्रोजेक्ट में प्रॉम्प्ट के रूप में होते हैं। /test टाइप करें और Mythex लाइव प्रीव्यू पर किसी यूज़र की तरह क्लिक करता है और टूटे फ़्लो की रिपोर्ट देता है — देखें App Testing। कुंजियां चैट के बजाय प्रोजेक्ट सीक्रेट्स में जाती हैं, हर सफल एजेंट टर्न आपकी फ़ाइलों का चेकपॉइंट सेव करता है जिस पर आप लौट सकते हैं, और पब्लिश करने पर होस्टिंग के साथ एक लाइव URL मिलता है, जिसमें ऐप और डेटाबेस एक ही क्रेडिट बैलेंस से बिल होते हैं (होस्टिंग सीमाएं बताता है कि ऐप और डेटाबेस कैसे सोते और जागते हैं)। चेकपॉइंट फ़ाइलों को कवर करते हैं, डेटाबेस रो को नहीं, इसलिए डेटा बैकअप की योजना फिर भी बनाएं। Pro प्लान पर आप कस्टम डोमेन जोड़ सकते हैं, और हैंडओवर के लिए कोड एक्सपोर्ट कर सकते हैं या अपने GitHub रिपॉज़िटरी से सिंक कर सकते हैं।

सवाल