पिछले अध्याय 4 "AI के साथ बनाना" में, चलती हुई चीज़ बन गई। यहाँ से आगे है फेज़ 4 "पब्लिश करना" — टेस्ट से जाँचना कि कहीं टूटती तो नहीं, सिक्योरिटी के छेद भरना, और फिर दुनिया के सामने पब्लिश करना। "चल गया" पर संतुष्ट न हों, इसे दूसरों के बेफ़िक्र छूने लायक हालत तक ले जाएँ। मुश्किल सुनाई देता है, पर यहाँ भी AI साथी बनता है।

इस अध्याय का लक्ष्य

"अधूरा भी चलेगा। पहले एक व्यक्ति तक, सुरक्षित पहुँचाएँ"

① टूटती तो नहीं, जाँचें
AI से बग, खतरनाक इनपुट, छूटे टेस्ट का ऑडिट करवाएँ, और एक-एक करके सुधारें।
② राज़ और दूसरों को बचाएँ
API कीज़ एनवायरनमेंट वैरिएबल में। दूसरों का डेटा बचाएँ, परमिशन न्यूनतम रखें।
③ दुनिया के सामने पब्लिश करें
फ़्री प्लान से काम। कोड इंटरनेट पर डालें, और URL एक व्यक्ति को दें।

"बना लिया" और "पब्लिश कर सकते हैं" अलग हैं

अपने कंप्यूटर पर चलने वाली चीज़, और दूसरों के छूने पर भी ठीक रहने वाली चीज़ — दोनों अलग हैं। आप "सही इस्तेमाल" जानते हैं, इसलिए उसे सोचे मुताबिक चलाते हैं। पर पब्लिश करें, तो आपके सोचे से परे इनपुट, ऑपरेशन और बदनीयती आती है। खाली भेजने वाले, ढेरों चिह्न पेस्ट करने वाले, दूसरों का डेटा ताकने की कोशिश करने वाले —।

पर इससे तनकर बैठने की ज़रूरत नहीं। पर्सनल डेवलपमेंट में सबसे पहले जो करना है, वह बस बेहद बुनियादी 3 बिंदु हैं। "टूटती तो नहीं", "राज़ लीक तो नहीं होता", "दूसरों का डेटा बचता है या नहीं"। यह अध्याय, उस न्यूनतम को AI के साथ पार करके, बेधड़क पब्लिश करने का अध्याय है।

🏠 सिर्फ़ खुद इस्तेमाल करते हों

सही क्रम से ही छूते हैं। एरर आए तो खुद ठीक कर लेते हैं। राज़ की जानकारी स्क्रीन पर दिखे तो परवाह नहीं।

🌍 दूसरों को पब्लिश कर दिया हो

सोचे से परे इनपुट आता है। एरर स्क्रीन से अंदरूनी जानकारी लीक होती है। गलती से पब्लिश हुई की से भारी बिल या डेटा लीक तक।

टेस्ट और रिव्यू AI को सौंपें

"अकेले डेवलपमेंट में, कोड रिव्यू करने वाला कोई सीनियर नहीं होता" — वह भूमिका ठीक AI को सौंप दें। आपने लिखा (या AI से लिखवाया) कोड, किसी और नज़रिए से एक बार फिर AI से जँचवाएँ। लिखने वाला खुद (इंसान हो या AI) अपनी गलती नोटिस नहीं कर पाता। इसलिए एक "ऑडिटर" बिठाना असरदार है।

तरीका सीधा है। कोड पेस्ट करके, बस इतना कहें: "इस कोड के बग, खतरनाक इनपुट और छूटे हुए टेस्ट गिनाओ"। तो जो छेद खुद नोटिस न कर पाए, वे लिस्ट बनकर लौटते हैं। बाकी बस एक-एक करके, ऊँची प्राथमिकता वालों से सुधारना। सबको एक साथ सुधारने की कोशिश न करें, एक बात सुधारकर चलाकर जाँचें, फिर एक और — यही कुंजी है।

AI से ऑडिट माँगते वक्त, नीचे जैसे नज़रिए साफ़ बता दें, तो सटीकता बढ़ती है।

🐛 बग / एरर

"किन हालात में गिरता है?" "खाली या ज़ीरो दें तो?" टूटने की शर्तें AI से ढुँढवाएँ।

⚠️ खतरनाक इनपुट

बदनीयत टेक्स्ट, विशाल डेटा, गलत फ़ाइल। "हमलावर होते तो कैसे घुसते?" पूछें।

🧪 छूटे हुए टेस्ट

"जो जाँचनी चाहिए पर जाँची नहीं ऐसी कौन-सी हालतें हैं?" सीमा-मान और अपवाद खँगलवाएँ।

🔒 राज़ का उजागर होना

"API की या पासवर्ड कोड में सीधे तो नहीं लिखा?" लीक की कली पहले ही तोड़ें।

💡 टेस्ट यानी "अपने-आप जाँचने वाला ढाँचा"। प्रैक्टिकल रूट हो, तो AI से टेस्ट कोड तक लिखवाएँ। "इस फ़ंक्शन का टेस्ट लिखो। नॉर्मल केस, और खाली-गलत मान वाले केस भी" कहें, तो अगली बार सुधारने पर कुछ टूटा तो नहीं, यह एक बटन से दोबारा जाँचा जा सकता है। बिगिनर रूट हो, तो हाथ से "जानबूझकर अजीब ऑपरेशन करके देखना" भी काफ़ी बड़ा कदम है।

सिक्योरिटी के न्यूनतम 3 बिंदु

सिक्योरिटी गहरा क्षेत्र है, पर पर्सनल डेवलपमेंट के पब्लिश करते वक्त पहले ज़रूर पकड़ने लायक बस 3 बिंदु याद रखें। इन तीन को चूकें, तो पैसा, भरोसा और दूसरों की जानकारी — सब एक झटके में गँवा सकते हैं। उलटे, बस इतना निभा लें तो पहली पब्लिश के लिए काफ़ी है।

पहला
🔑 राज़ एनवायरनमेंट वैरिएबल में

API की, पासवर्ड, टोकन को कोड में सीधे न लिखें। .env जैसी एनवायरनमेंट वैरिएबल फ़ाइल में डालें, और उस फ़ाइल को पब्लिश से बाहर रखें (.gitignore में जोड़ें)।

दूसरा
🛡️ दूसरों का डेटा बचाएँ

लॉगिन फ़ीचर हो, तो A नाम का व्यक्ति अपने अलावा किसी और का डेटा न देख सके, यह पक्का करें। "यह डेटा सच में इसी व्यक्ति का है?" वाला ओनरशिप-चेक, AI से जँचवाकर ज़रूर डालें।

तीसरा
🔐 परमिशन न्यूनतम रखें

बाहरी सर्विस की कीज़ या DB की परमिशन बस ज़रूरत जितनी। "सब कुछ कर सकने वाली" की न बाँटें। इस्तेमाल-भर-की की, सिर्फ़-पढ़ने वाली की — मकसद सिकोड़कर जारी करें।

🚨 सीक्रेट की कभी पब्लिश न करें। यह पर्सनल डेवलपमेंट में सबसे आम, और सबसे महँगा पड़ने वाला हादसा है। API की कोड में सीधे लिखकर उसी तरह GitHub आदि पर पब्लिश कर दें, तो कुछ मिनट से कुछ घंटों में अपने-आप ढूँढ ली जाती है और गलत इस्तेमाल होती है। पेड API हो तो जब तक नोटिस हो, तब तक लाखों का बिल — ऐसा असल में होता है। पब्लिश से पहले "की कोड में तो नहीं रह गई" यह ज़रूर AI से जँचवाएँ। एक बार पब्लिश हो चुकी की को मिटाना काफ़ी नहीं। उसे ज़रूर निष्क्रिय करके नई की जारी करवाएँ।

"मुश्किल लगता है" महसूस हो, तो AI से बस इतना पूछें, काम बन जाएगा: "इस कोड को पब्लिश करने से पहले, सिक्योरिटी के लिहाज़ से क्या करना चाहिए, बिगिनर के लिए बताओ"। आपके कोड के मुताबिक ठोस चेकलिस्ट लौट आती है।

ऑटोमेशन सुरक्षित तरीके से चलाएँ (प्रैक्टिकल के लिए)

यह मुख्य रूप से 🔧प्रैक्टिकल रूट के लिए बात है। Claude Code जैसे AI एजेंट को फ़ाइल ऑपरेशन और कमांड रन अपने-आप सौंप दें, तो डेवलपमेंट एकदम तेज़ हो जाता है। पर दूसरी ओर, "अपने-आप कोई ज़रूरी फ़ाइल मिटा देना", "अनचाही कमांड चला देना" जैसे बेकाबू होने का जोखिम भी ज़ीरो नहीं।

इसीलिए अहम है "आइसोलेशन (सैंडबॉक्स)" की सोच। AI को मज़बूत परमिशन देते वक्त, उसे ऐसे डिब्बे में चलाएँ जहाँ नुकसान पहुँचे भी तो दिक्कत न हो। ठोस रूप में, एक खास वर्क-फ़ोल्डर या कंटेनर में बंद कर दें, ताकि वह प्रोडक्शन डेटा या राज़ की जानकारी छू न सके। ऐसा करें, तो AI को ऑटोमेशन बेफ़िक्र सौंपा जा सकता है।

📦 "आज़माना डिब्बे के अंदर, प्रोडक्शन धीरे-धीरे" ही सिद्धांत है। AI का ऑटो-रन, सीधे प्रोडक्शन एनवायरनमेंट या ज़रूरी डेटा पर न चलाएँ। आइसोलेशन का ठोस तरीका Claude Code का सैंडबॉक्स सेटिंग गाइड में विस्तार से बताया है। बिगिनर रूट वाले, इस सेक्शन को "अच्छा, ऐसा सुरक्षा-उपाय भी है" जान लेना भर काफ़ी है।

पब्लिश करना — कोड से इंटरनेट पर पब्लिश तक

अब आई पब्लिश की बारी। "पब्लिश" यानी, आपके कंप्यूटर के भीतर की चीज़ को इंटरनेट पर रखकर, कोई भी URL से खोल सके ऐसी हालत में लाना। इसे डिप्लॉय कहते हैं। सुनने में मुश्किल लगता है, पर आजकल फ़्री सर्विस पर चंद क्लिक में चढ़ाया जा सकता है।

मोटा तौर पर बहाव नीचे के 3 कदम हैं। पर्सनल डेवलपमेंट की पहली पब्लिश, पूरी तरह फ़्री प्लान में आराम से हो जाती है। पैसा तब लगाएँ जब इस्तेमाल करने वाले बढ़ने लगें।

STEP 1
कोड रखें

GitHub आदि पर कोड सेव करें। राज़ फ़ाइल (.env) बाहर रखना न भूलें। यही पब्लिश की बुनियाद बनती है।

STEP 2
पब्लिश सर्विस से जोड़ें

Vercel जैसी फ़्री होस्टिंग से GitHub जोड़ें। राज़ जानकारी मैनेजमेंट स्क्रीन से एनवायरनमेंट वैरिएबल के रूप में रजिस्टर करें।

STEP 3
URL पाएँ

अपने-आप इंटरनेट पर बिल्ड होकर, पब्लिक URL जारी होता है। बाकी बस वह URL एक व्यक्ति को देना।

✅ अधूरा भी हो, पब्लिश करके एक व्यक्ति को दिखाएँ। "अभी फ़ीचर कम हैं", "डिज़ाइन ठीक नहीं" — इसी भाव में पब्लिश टालते रहना ही, पर्सनल डेवलपमेंट के गुम होने की सबसे बड़ी वजह है। 60 अंक चलेगा। पब्लिक URL अपने करीबी एक व्यक्ति को भेजने तक कर डालें। उसका "यहाँ इस्तेमाल करना मुश्किल है" वाला एक वाक्य, 100 घंटे की उलझन से ज़्यादा कीमती है।

ठोस कदम — GitHub पर सेव से लेकर Vercel पर पब्लिश और एनवायरनमेंट वैरिएबल सेटिंग तक — Claude Code / Cursor से बनाकर Vercel पर पब्लिश करने के कदम में स्क्रीन-सहित बताए हैं। अटकें, तो वैसे ही AI से "इस स्क्रीन पर एरर आया, क्या करूँ?" पूछें, अकसर निकल आते हैं।

इस अध्याय का सार
  • अकेले होकर भी रिव्यू की भूमिका AI को। "बग, खतरनाक इनपुट, छूटे टेस्ट गिनाओ" से ऑडिट करवाएँ, एक-एक सुधारें।
  • सिक्योरिटी के न्यूनतम 3: राज़ एनवायरनमेंट वैरिएबल में／दूसरों का डेटा बचाएँ／परमिशन न्यूनतम।
  • सीक्रेट की कभी पब्लिश न करें। लीक हो तो मिटाना नहीं, निष्क्रिय करना और फिर से जारी करना। पब्लिश से पहले AI से जाँच।
  • पब्लिश (डिप्लॉय) फ़्री प्लान से काम। अधूरा भी हो, URL एक व्यक्ति को देने तक कर डालें।

इससे "बनाकर, सुरक्षित तरीके से पब्लिश करने" तक पहुँच गए। पर असली मुकाबला यहाँ से है। इस्तेमाल करवाना, सुधारना, और टिकाऊ रूप देना — यह आखिरी फेज़ है। अगले अध्याय 6 "बढ़ाना — यूज़र जुटाना और कमाई" की ओर बढ़ें।