सीधे कंटेंट पर जाएँ

क्या आपका AI से बना app असली यूज़र्स के लिए तैयार है?

Plutonapps की production-readiness जाँच, Lovable या किसी भी AI builder से बने app को लगभग तीन मिनट में 100 में से स्कोर देती है। सुरक्षा, डेटा, releases, monitoring, payments, privacy और ownership पर 19 सवालों के जवाब दें, और देखें कि सबसे पहले कौन-से तीन जोखिम ठीक करने हैं। यह मुफ़्त है, और आपके जवाब इसी पेज में रहते हैं, जब तक आप ईमेल से पूरी रिपोर्ट न माँगें।

सवाल

सुरक्षा और access

कौन sign in कर सकता है, और database उनमें से हर एक को क्या पढ़ने देता है।

1.लोग आपके app में sign in कैसे करते हैं?

Sign-in यानी authentication: यह साबित करना कि कोई कौन है।

2.क्या production बदल सकने वाले हर अकाउंट — Supabase, hosting, GitHub, Stripe, आपका domain — पर multi-factor authentication चालू है?

इनमें से किसी पर भी एक phish किया हुआ पासवर्ड हर चीज़ में घुसने का रास्ता है।

3.क्या यूज़र डेटा रखने वाली हर table पर row-level security चालू है, ऐसी policies के साथ जिन्हें आपने दूसरे यूज़र के रूप में टेस्ट किया है?

RLS ही वह चीज़ है जो एक signed-in यूज़र को आपकी public API के ज़रिए दूसरे की rows पढ़ने से रोकती है।

4.आपकी Supabase service-role (secret) key कहाँ रहती है?

Service-role key row-level security को पूरी तरह बाईपास कर देती है।

5.आपके बाकी secrets कहाँ रखे हैं — Stripe secret key, ईमेल और AI API keys?

Git repository में रखा secret डिलीट करने के बाद भी उसकी history में रहता है।

डेटा की सुरक्षा

क्या आपका डेटा एक ख़राब deploy, एक ख़राब prompt या एक बुरे दिन से बच पाता है।

6.अगर दोपहर 3 बजे किसी ख़राब बदलाव ने एक table मिटा दी, तो आप क्या restore कर सकते थे?

रोज़ाना backups पिछले backup के बाद का सब कुछ खो देते हैं; point-in-time recovery नहीं।

7.क्या आपने यह साबित करने के लिए किसी अलग प्रोजेक्ट में backup restore किया है कि वह काम करता है?

जिस backup को किसी ने restore नहीं किया, वह योजना नहीं, उम्मीद है।

8.Database के बदलाव production तक कैसे पहुँचते हैं?

Migration एक versioned SQL फ़ाइल है, जो हर जगह एक ही तरह लागू होती है।

Releases और टेस्टिंग

आपके यूज़र्स के देखने से पहले किसी बदलाव की जाँच कैसे होती है।

9.क्या कोई staging environment है, अपने अलग database के साथ, जहाँ बदलाव पहले जाँचे जाते हैं?

Staging production की एक निजी कॉपी है, जहाँ हर release लाइव होने से पहले आज़माई जाती है।

10.क्या ऑटोमेटेड टेस्ट आपके मुख्य flows — sign-up, payment और आपके app का मुख्य काम — को कवर करते हैं?

Regression tests पकड़ते हैं कि जिस फ़ीचर को आपने छुआ नहीं, वह किसी दूसरे बदलाव की वजह से टूट गया।

11.कोड production तक कैसे पहुँचता है?

CI/CD हर बदलाव पर वही जाँचें चलाता है और सिर्फ़ वही deploy करता है जो पास हो।

लाइव चलाना

यूज़र्स के बताने से पहले पता होना कि कुछ टूटा है, और उसके बाद क्या होता है।

12.अगर अभी app यूज़र्स के लिए टूट जाए, तो आपको कैसे पता चलेगा?

Observability का मतलब है logs, metrics और errors से जानना कि चलता हुआ सिस्टम क्या कर रहा है।

13.क्या sign-up, login और ईमेल भेजने या किसी paid API (जैसे AI model) को call करने वाली हर चीज़ पर rate limit है?

बिना सीमा के, एक script आपका बिल बढ़ा सकती है या आपके यूज़र्स को लॉक आउट कर सकती है।

14.अगर आज रात production बंद हो जाए, तो क्या कोई नामित व्यक्ति और लिखित योजना है?

Incident response का मतलब है पहले से तय करना कि कौन और कैसे कार्रवाई करेगा।

पेमेंट

कार्ड डेटा रखे बिना या ब्राउज़र पर भरोसा किए बिना पैसे लेना।

15.आपका app payments कैसे लेता है?

कार्ड की जानकारी किसके पास है, इससे तय होता है कि compliance का कितना काम आप पर आता है।

16.क्या आने वाले webhooks signature से जाँचे जाते हैं, और क्या उन्हें दो बार पाना सुरक्षित है?

Providers webhooks दोबारा भेजते हैं, इसलिए एक ही event एक से ज़्यादा बार आ सकता है।

Privacy और compliance

GDPR की बुनियादी बातें, और किसने क्या बदला इसका रिकॉर्ड।

17.क्या आपके पास GDPR की बुनियादी चीज़ें हैं: अपने providers के नाम वाली privacy policy, हर एक के साथ data processing agreement, और माँगने पर किसी यूज़र का डेटा डिलीट करने का तरीका?

अगर आपके यूज़र्स EU या UK में हैं, तो ये क़ानूनी कर्तव्य हैं, अतिरिक्त चीज़ें नहीं।

18.क्या आप बता सकते हैं कि आपके admin हिस्से में किसने क्या बदला, और कब?

Audit log अहम कार्रवाइयों का ऐसा रिकॉर्ड है जिसमें सिर्फ़ जोड़ा जा सकता है।

मालिकाना हक़

क्या app आपका है, जिसे आप कहीं ले जा सकें, सौंप सकें और चालू रख सकें।

19.क्या कोड आपकी अपनी Git repository में है, और क्या कोई दूसरी टीम उसे बनाने वाले व्यक्ति के बिना deploy कर सकती है?

अगर सिर्फ़ एक टूल या एक व्यक्ति ही इसे ship कर सकता है, तो आप बँधे हुए हैं।

0 / 19 के जवाब दिए गए

स्कोर कैसे बनता है

हर सवाल का एक तय वज़न है, और सारे वज़न मिलकर 100 होते हैं। आपका जवाब उसका पूरा, कुछ हिस्सा या कुछ भी नहीं कमाता है; “पक्का नहीं” कुछ नहीं कमाता। जो सवाल आपके app पर लागू नहीं होता, उसे छोड़ दिया जाता है और बाकी को फिर से 100 के पैमाने पर लाया जाता है। कोई भी critical कमी स्कोर को 49 पर रोक देती है। नियम आपके ब्राउज़र में और हमारे सर्वर पर एक जैसे हैं, और इसमें कोई AI शामिल नहीं है।

हर क्षेत्र का वज़न, 100 में से
क्षेत्रसवालवज़न
सुरक्षा और access525
डेटा की सुरक्षा320
Releases और टेस्टिंग315
लाइव चलाना315
पेमेंट210
Privacy और compliance210
मालिकाना हक़15

श्रेणियाँ: 90 और उससे ऊपर production के लिए तैयार, 75 से 89 लगभग तैयार, 50 से 74 पर काम बाकी, 50 से नीचे तैयार नहीं। हर शब्द का मतलब हमारी शब्दावली में है।

जाँच के बारे में सवाल

Production-readiness जाँच क्या मापती है?

सात क्षेत्रों में 19 सवाल, जो तय करते हैं कि कोई app असली यूज़र्स के लिए सुरक्षित है या नहीं: सुरक्षा और access, डेटा की सुरक्षा, releases और टेस्टिंग, लाइव चलाना, payments, privacy और compliance, और ownership। हर जवाब को एक तय वज़न पर आँका जाता है, और सारे क्षेत्र मिलकर 100 होते हैं।

स्कोर की गणना कैसे होती है?

हर सवाल का एक वज़न है, और सारे वज़न मिलकर 100 होते हैं। आपका जवाब उस वज़न का पूरा, कुछ हिस्सा या कुछ भी नहीं कमाता है। "पक्का नहीं" कुछ नहीं कमाता, क्योंकि अगर आप नहीं कह सकते कि काम हो गया है, तो सुरक्षित मान्यता यही है कि नहीं हुआ। जो सवाल आपके app पर लागू नहीं होता, जैसे payments जब आप कोई payment नहीं लेते, उसे छोड़ दिया जाता है और बाकी को फिर से 100 के पैमाने पर लाया जाता है। कोई critical कमी, जैसे ब्राउज़र में service-role key, स्कोर को 49 पर रोक देती है। यही नियम हमारे सर्वर पर चलते हैं, बिना किसी AI के।

कौन-सा स्कोर production के लिए तैयार माना जाता है?

90 या उससे ज़्यादा production के लिए तैयार है, 75 से 89 लगभग तैयार, 50 से 74 पर लॉन्च से पहले काम बाकी है, और 50 से नीचे असली यूज़र्स के लिए तैयार नहीं। कोई एक भी critical कमी app को 50 से नीचे रखती है, बाकी चाहे जो भी तैयार हो।

क्या आप मेरे जवाब सेव करते हैं?

नहीं, जब तक आप ईमेल वाली रिपोर्ट न माँगें। स्कोर आपके ब्राउज़र में निकाला जाता है। अगर आप रिपोर्ट माँगते हैं, तो हम 24 महीनों के लिए आपका ईमेल, आपका दिया नाम और app का पता, आपके जवाब, आपका स्कोर, अपडेट वाले बॉक्स पर आपने टिक किया या नहीं, लिंक के campaign tags और वह पेज जिसने आपको भेजा (अगर आपका ब्राउज़र Do Not Track या Global Privacy Control भेजता है तो इनमें से कोई नहीं), और आपके IP पते का one-way hash सेव करते हैं। हम रिपोर्ट एक बार भेजते हैं और अपनी टीम को बताते हैं। बॉक्स पर टिक करने पर ही हम आपको कुछ और भेजते हैं। हम आपके app के पते पर कभी नहीं जाते, न उसे स्कैन करते हैं।

क्या यह सिर्फ़ Lovable से बने apps के लिए है?

नहीं। यह किसी भी AI app builder, जैसे Lovable, Bolt, v0 या Replit, से बने या हाथ से बने किसी भी app के लिए काम करती है। कुछ सवालों में Supabase का नाम है क्योंकि AI से बने ज़्यादातर apps उसी पर चलते हैं, लेकिन यही जाँचें database, sign-in और payments वाले किसी भी app पर लागू होती हैं।

मुझे सबसे पहले क्या ठीक करना चाहिए?

उन तीन जोखिमों से शुरू करें जो जाँच आपको दिखाती है। पहले critical कमियाँ, फिर वे जवाब जिन्होंने सबसे ज़्यादा अंक गँवाए। हर एक हमारी शब्दावली में आसान भाषा की परिभाषा से जुड़ा है। अगर आप चाहते हैं कि इंजीनियर इन्हें ठीक करें, तो Plutonapps प्लान यही करता है।

चाहते हैं कि इंजीनियर इसे आपके लिए ठीक करें?

आप Lovable में डिज़ाइन करते रहिए। Plutonapps के इंजीनियर सब्सक्रिप्शन पर असली प्रोडक्ट को सुरक्षित, टेस्ट किया हुआ और production के लिए तैयार बनाते हैं।

प्लान देखें