आपका पहला वर्ज़न भरोसेमंद दिखता है। आप डैशबोर्ड दिखा सकते हैं, एक सैंपल रिकॉर्ड बना सकते हैं और चेकआउट तक क्लिक कर सकते हैं। असली सवाल यह है कि क्या कोई ऐसा व्यक्ति, जिसने आपका ऐप कभी नहीं देखा, कल यही काम कर पाएगा। यह AI MVP प्रोडक्शन चेकलिस्ट इसी अंतर को भरने के लिए है, चाहे आपने शुरुआत Lovable, Bolt, Replit, Base44 या किसी और बिल्डर से की हो।
MVP के लिए प्रोडक्शन-रेडी होने का मतलब क्या है?
प्रोडक्शन-रेडी MVP अपने तय ग्राहकों को अपना सीमित वादा भरोसेमंद तरीके से पूरा करता है, सही एक्सेस कंट्रोल के साथ और एक व्यावहारिक रिकवरी प्लान के साथ। इसके लिए आपके रोडमैप का हर फ़ीचर ज़रूरी नहीं है, न ही ऐसा इन्फ्रास्ट्रक्चर जो उन यूज़र्स के लिए बना हो जो अभी आपके पास हैं ही नहीं।
| डेमो से साबित होता है | ग्राहक रिलीज़ को साबित करना होगा |
|---|---|
| स्क्रीन रेंडर हो सकती है | नए अकाउंट से मुख्य जर्नी काम करती है |
| एक सैंपल रिकॉर्ड मौजूद है | रिकॉर्ड सेव होते हैं और सिर्फ़ सही यूज़र्स को दिखते हैं |
| चेकआउट खुलता है | फेल होने और दोबारा कोशिश के बाद भी पेमेंट स्टेट सही रहती है |
| ऐप पब्लिश हो सकता है | कोई गड़बड़ी पकड़ सकता है और सर्विस को रिकवर कर सकता है |
नीचे दी गई जांचों को रिलीज़ के सबूत की तरह लें। हर जांच के लिए दर्ज करें कि किसने टेस्ट किया, कौन-सा URL और वर्ज़न इस्तेमाल किया, और क्या हुआ। जिस आइटम का टेस्ट नहीं हुआ, उसे अज्ञात मार्क करें। साफ़-सुथरा दिखने वाला इंटरफ़ेस या AI का यह मैसेज कि समस्या ठीक हो गई है, टेस्ट का नतीजा नहीं है।
क्या नया यूज़र मुख्य जर्नी पूरी कर सकता है?
नए ग्राहक को आपकी मदद के बिना प्रोडक्ट के उपयोगी नतीजे तक पहुंच जाना चाहिए। पब्लिश किए गए ऐप पर पूरी जर्नी को ऐसे अकाउंट से टेस्ट करें जिसके पास पहले से कोई अनुमति, सेव किया हुआ सेशन या सैंपल डेटा न हो।
- जांच 1 — पहला इस्तेमाल: साइन अप करें, ज़रूरत हो तो ईमेल कन्फ़र्म करें, पहला उपयोगी आइटम बनाएं, बाहर निकलें और फिर लौटें। हर वह निर्देश दर्ज करें जो आपको ज़बानी समझाना पड़ा; फ़्लो या उसके शब्दों को बेहतर बनाएं।
- जांच 2 — अकाउंट रिकवरी: साइन आउट करें, जहां सपोर्ट हो वहां पासवर्ड रीसेट करें, एक्सपायर हो चुके लिंक को खोलें, और सेशन खत्म होने के बाद लौटें। जांचें कि रिकवरी लाइव डोमेन पर ही पहुंचती है और ग्राहक अपना काम जारी रख पाता है।
क्या यूज़र्स सिर्फ़ वही डेटा देख पाते हैं जो उन्हें देखना चाहिए?
ऑथेंटिकेशन यूज़र की पहचान करता है; ऑथराइज़ेशन तय करता है कि वह यूज़र क्या एक्सेस कर सकता है। लॉगिन चलने से यह साबित नहीं होता कि ग्राहकों के रिकॉर्ड, अपलोड की गई फ़ाइलें या एडमिन एक्शन सुरक्षित हैं।
Supabase इस्तेमाल करने वाले ऐप्स के लिए, उसका row-level security डॉक्यूमेंटेशन बताता है कि डेटाबेस पॉलिसी कैसे रो एक्सेस को सीमित करती हैं। अपने असली ओनरशिप नियमों के हिसाब से इम्प्लीमेंटेशन का रिव्यू करवाएं। दूसरे बैकएंड्स के लिए उनके अपने परमिशन मॉडल के आधार पर ऐसी ही जांच ज़रूरी है।
- जांच 3 — ग्राहकों का अलगाव: दो सामान्य यूज़र बनाएं, दोनों का एक-एक निजी रिकॉर्ड हो। किसी डेवलपर से पुष्टि करवाएं कि रिक्वेस्ट में रिकॉर्ड आइडेंटिफ़ायर बदलने से दूसरे यूज़र का रिकॉर्ड न दिखे और न बदले।
- जांच 4 — विशेषाधिकार वाले एक्शन: सर्वर पर पुष्टि करें कि कोई सामान्य यूज़र खुद को पेड प्लान नहीं दे सकता, एडमिन को इनवाइट नहीं कर सकता, या URL का अंदाज़ा लगाकर निजी अपलोड तक नहीं पहुंच सकता। साइन आउट रहते हुए यही जांच दोहराएं।
क्या पेमेंट और इंटीग्रेशन गड़बड़ियों को झेल पाते हैं?
भरोसेमंद इंटीग्रेशन फेल होने और दोबारा कोशिश को इस तरह संभालता है कि न काम खोए, न गलत एक्सेस मिले। चेकआउट एनिमेशन देखकर सफलता तय करने के बजाय, अपने ऐप्लिकेशन में सेव हुई स्टेट की पुष्टि करें।
अगर आप Stripe इस्तेमाल करते हैं, तो उसका webhook डॉक्यूमेंटेशन एसिंक्रोनस पेमेंट इवेंट्स, सिग्नेचर वेरिफ़िकेशन और डुप्लिकेट डिलीवरी के बारे में बताता है। आपके इंटीग्रेशन को आने वाले इवेंट्स वेरिफ़ाई करने चाहिए और एक ही इवेंट को दो बार पूरा करने से बचना चाहिए। सटीक इवेंट्स आपके पेमेंट फ़्लो पर निर्भर करते हैं।
- जांच 5 — पेमेंट स्टेट: प्रोवाइडर के टेस्ट एनवायरनमेंट में सफल, फेल, कैंसल और देर से होने वाले पेमेंट टेस्ट करें। पुष्टि करें कि एक्सेस तभी बदलता है जब सही, वेरिफ़ाई किया गया सर्वर-साइड इवेंट आता है।
- जांच 6 — बाहरी सर्विस की गड़बड़ी: नियंत्रित टेस्ट में ईमेल प्रोवाइडर, AI सर्विस या किसी दूसरे ज़रूरी इंटीग्रेशन को फेल करवाएं। यूज़र को समझ आने वाला नतीजा दिखना चाहिए और डुप्लिकेट चार्ज या डुप्लिकेट रिकॉर्ड के बिना दोबारा कोशिश करने का सुरक्षित तरीका मिलना चाहिए।
क्या लाइव ऐप सही डेटा सुरक्षित रखेगा?
पब्लिश किया गया ऐप तय प्रोडक्शन डेटाबेस से जुड़ा होना चाहिए और ग्राहकों की फ़ाइलों के लिए स्थायी स्टोरेज इस्तेमाल करना चाहिए। डेटा से भरा प्रीव्यू यह साबित नहीं करता कि लाइव ऐप का सेटअप भी वैसा ही है।
- जांच 7 — एनवायरनमेंट का अलगाव: पहचानें कि हर एनवायरनमेंट कौन-सा डेटाबेस इस्तेमाल करता है। पुष्टि करें कि किसी फ़ीचर की टेस्टिंग से लाइव ग्राहकों के रिकॉर्ड नहीं बदल सकते, और दर्ज करें कि मंज़ूर किए गए स्कीमा बदलाव प्रोडक्शन तक कैसे पहुंचते हैं।
- जांच 8 — स्थायित्व और रिकवरी: एक रिकॉर्ड सेव करें और एक फ़ाइल अपलोड करें, फिर नियंत्रित रीस्टार्ट या डिप्लॉयमेंट के बाद जांचें कि वे उपलब्ध हैं या नहीं। बैकअप की ज़िम्मेदारी किसकी है, यह तय करें और इस प्रक्रिया पर भरोसा करने से पहले एक सुरक्षित कॉपी पर रिकवरी का अभ्यास करें।
Replit साफ़ तौर पर अलग डेवलपमेंट और प्रोडक्शन डेटाबेस के बारे में डॉक्यूमेंट करता है। किसी भी बिल्डर के लिए यही व्यावहारिक सवाल पूछें: लाइव डेटा कहां है, उसे कौन बदल सकता है, और हम उसे कैसे रिकवर करेंगे? यह मानने के बजाय कि हर प्लेटफ़ॉर्म एक जैसा काम करता है, अपने अकाउंट की क्षमताएं जांचें।
क्या आप गड़बड़ी पकड़कर रिलीज़ को रिकवर कर सकते हैं?
किसी को यह पता चलना चाहिए कि ग्राहक की जर्नी फेल हुई है और आगे क्या करना है। एरर की जानकारी और रिकवरी प्रक्रिया होने से छोटे लॉन्च को चलाना कहीं आसान हो जाता है।
- जांच 9 — काम के एरर सबूत: एक हानिरहित टेस्ट फ़ेलियर ट्रिगर करें और उससे जुड़ा सर्वर एरर या फेल रिक्वेस्ट ढूंढें। पासवर्ड, निजी दस्तावेज़ या पेमेंट क्रेडेंशियल लॉग किए बिना समय और ऑपरेशन दर्ज करें।
- जांच 10 — रिलीज़ रिकवरी: आखिरी बार ठीक से चलने वाले कोड वर्ज़न को पहचानें, यह तय करें कि उसे कौन रीस्टोर कर सकता है, और वह किन डेटाबेस बदलावों की अपेक्षा रखता है। कोड रीस्टोर करने से डेटा में हुए बदलाव अपने-आप वापस नहीं होते; दोनों प्रक्रियाओं का अलग-अलग अभ्यास करें।
क्या प्रोडक्ट आपके डेमो सेटअप के बाहर भी काम करता है?
ग्राहक रिलीज़ को उन डिवाइसों और नेटवर्क हालात में काम करना चाहिए जो आपके पहले यूज़र्स के पास असल में हैं। सिर्फ़ छोटे सैंपल नामों और तेज़ ऑफ़िस कनेक्शन के बजाय, असली जैसे कंटेंट के साथ प्रोडक्ट को जांचें।
- जांच 11 — रोज़मर्रा की उपयोगिता: मुख्य जर्नी को एक संकरी फ़ोन स्क्रीन पर और कीबोर्ड नेविगेशन के साथ पूरा करें। लंबे नाम, खाली लिस्ट, वैलिडेशन एरर और बीच में रुके अपलोड आज़माएं। लोडिंग और फ़ेलियर स्टेट्स को समझने लायक बनाएं।
- जांच 12 — लॉन्च के समय का अपेक्षित लोड: शुरुआती ऑडियंस पर सहमति बनाएं और डेटा की प्रतिनिधि मात्रा और एक साथ होने वाली गतिविधि के साथ टेस्ट करें। रिस्पॉन्स टाइम और रिसोर्स इस्तेमाल पर नज़र रखें। जहां सपोर्ट हो वहां खर्च की सीमा या अलर्ट सेट करें, और तय करें कि किस स्थिति में किसी को जांच करनी चाहिए।
ग्राहकों को बुलाने से पहले क्या ठीक करना चाहिए?
ऑडियंस बढ़ाने से पहले टूटी हुई मुख्य जर्नी, गलत पेमेंट एक्सेस और अनुचित डेटा एक्सेस को ठीक करें। वैकल्पिक फ़ीचर्स और दिखावटी सुधारों को इन प्राथमिकताओं के हिसाब से शेड्यूल करें।
एक काल्पनिक अपॉइंटमेंट ऐप लें: फाउंडर के लिए बुकिंग काम करती है, लेकिन नया यूज़र अपना अकाउंट रिकवर नहीं कर पाता, फेल हुआ पेमेंट भी कन्फ़र्म बुकिंग बना देता है, और दो टैब एक ही स्लॉट रिज़र्व कर सकते हैं। अगली रिलीज़ में इन्हीं रास्तों को ठीक करना चाहिए। चैट जोड़ने या डैशबोर्ड को नए सिरे से डिज़ाइन करने से लॉन्च की रुकावटें दूर नहीं होंगी।
अगर डीबगिंग ही अटक गई है, तो Lovable और Bolt फ़िक्स-लूप गाइड देखें। अगर अगला कदम मोबाइल से जुड़ा है, तो मौजूदा Lovable App Store गाइड पढ़ें। सीधी मदद के लिए, अपने MVP को प्रोडक्शन तक ले जाने पर कॉल बुक करें। ऐप का लिंक और अपनी फेल हुई जांचें साथ लाएं; हम सबूतों के आधार पर अगली रिलीज़ का दायरा तय कर सकते हैं।
अक्सर पूछे जाने वाले सवाल
क्या मैं AI ऐप बिल्डर से बना ऐप लॉन्च कर सकता हूं?
हां, AI से बना ऐप तब लॉन्च किया जा सकता है जब उसका इम्प्लीमेंटेशन और होस्टिंग प्रोडक्ट की ज़रूरतों को पूरा करें। असली यूज़र जर्नी, ऑथराइज़ेशन, पेमेंट का व्यवहार, डेटा हैंडलिंग और रिकवरी प्रक्रिया का आकलन करें। सिर्फ़ बिल्डर के नाम से तैयारी साबित नहीं होती, और चलता हुआ प्रीव्यू नए ग्राहक अकाउंट्स के साथ पब्लिश किए गए ऐप्लिकेशन की टेस्टिंग की जगह नहीं ले सकता।
क्या ग्राहक लाने से पहले मुझे अपना MVP दोबारा बनाना होगा?
दोबारा बनाना डिफ़ॉल्ट अगला कदम नहीं है। एक ऐसे रिव्यू से शुरुआत करें जो काम के कोड और प्रोडक्ट फ़्लो को खास जोखिमों या सीमाओं से अलग करे। एक सीमित रिलीज़ से अहम समस्याएं हल हो सकती हैं। किसी कंपोनेंट को बदलने या दोबारा बनाने पर तभी विचार करें जब सबूत दिखाएं कि मौजूदा तरीके को बनाए रखना तय ज़रूरतों के लिए उपयुक्त नहीं होगा।
अपने AI MVP का रिव्यू करने वाले डेवलपर के पास मुझे क्या लेकर जाना चाहिए?
ऐप का URL, उसकी मुख्य जर्नी का वॉकथ्रू, रिपॉज़िटरी या प्रोजेक्ट का उचित एक्सेस, और दोबारा दोहराई जा सकने वाली गड़बड़ियों की लिस्ट लाएं। यह भी बताएं कि ऑथेंटिकेशन, पेमेंट, डेटा और फ़ाइलें कौन-सी सर्विसेज़ संभालती हैं, लेकिन ब्रीफ़ में क्रेडेंशियल पेस्ट न करें। अगला ग्राहक माइलस्टोन बताएं, ताकि रिव्यू से खुला-छोड़ा रीबिल्ड प्रस्ताव नहीं, बल्कि एक केंद्रित दायरा निकले।
स्रोत और आगे पढ़ें
नीतियाँ बदलती रहती हैं। सबमिट करने से पहले आधिकारिक डॉक्यूमेंटेशन ज़रूर देखें।
- Supabase: Row Level Security (रो-लेवल सिक्योरिटी) ↗27 अक्टू॰ 2026 को जाँचा गया
- Lovable: सिक्योरिटी का अवलोकन ↗27 अक्टू॰ 2026 को जाँचा गया
- Stripe: वेबहुक्स ↗27 अक्टू॰ 2026 को जाँचा गया
- Replit: डेवलपमेंट और प्रोडक्शन डेटाबेस ↗27 अक्टू॰ 2026 को जाँचा गया
चलिए आपके ऐप को मंज़िल तक पहुँचाते हैं।
एक केंद्रित कॉल, यह समझने के लिए कि आपके ऐप और लाइव लिस्टिंग के बीच क्या रुकावट है।
कॉल बुक करें ↗
