Lovable app production में नहीं चल रहा? इसे production-ready कैसे बनाएँ

मेरा Lovable app preview में चलता है पर production में क्यों टूटता है?

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

• यूज़र्स के बीच डेटा लीक। Supabase किसी exposed schema की table को उस पर grant वाले किसी भी role के लिए पढ़ने और लिखने लायक बना देता है, जब तक row-level security चालू न हो और उसकी policies सही न हों।
• ब्राउज़र में secrets। Publishable (anon) key ship करना सुरक्षित है; service role key हर RLS policy को बाईपास करती है और उसे कभी ब्राउज़र तक नहीं पहुँचना चाहिए।
• भटकते payments। Success पेज पर लौटने वाला checkout भुगतान का सबूत नहीं है। सर्वर को Stripe से इसकी पुष्टि करनी होती है।
• पुराने फ़ीचर्स तोड़ने वाले बदलाव। Regression tests के बिना, हर नया prompt पिछले हफ़्ते चल रही किसी चीज़ को बिगाड़ सकता है।
• चुपचाप होने वाले outages। बिना monitoring के, bug आपसे पहले आपके ग्राहकों को मिलता है।

इनमें से कुछ भी सिर्फ़ Lovable तक सीमित नहीं है। कोई भी तेज़ पहला version, चाहे इंसान ने लिखा हो या AI ने, आम तौर पर इन्हीं कमियों के साथ आता है, क्योंकि प्रोटोटाइप का काम आइडिया साबित करना है, अजनबियों के बीच टिके रहना नहीं।

क्या Lovable app शुरू से ही production-ready होता है?

कुछ हद तक। Lovable की अपनी documentation कहती है कि Supabase जोड़ने पर वह tables के लिए row-level security policies लिखता है, publish करने पर एक तेज़ security scan चलाता है (database रिव्यू, जैसे बिना RLS वाली tables या सबको अंदर आने देने वाले नियम, dependency audit और MCP server check), और एक गहरा स्कैन देता है जिसे आप हाथ से शुरू करते हैं। वह साफ़ यह भी कहती है कि स्कैन पूरी सुरक्षा की गारंटी नहीं दे सकता और पूरी security review की जगह नहीं लेता।

यह एक उचित वर्णन है। स्कैन बता सकता है कि policy मौजूद है। वह यह नहीं बता सकता कि policy आपके बिज़नेस नियमों से मेल खाती है, जैसे कि टीम का admin invoices देख सकता है पर टीम का सदस्य नहीं। व्यवहार में production-ready का मतलब यही समझ है।

Lovable app के लिए production-ready का क्या मतलब है?

Lovable app में Stripe payments सुरक्षित तरीके से कैसे जोड़ें?

Lovable का Stripe integration edge functions के ज़रिए चलता है, इसलिए आपकी secret key app से बाहर रहती है, और एक बार के payments Stripe Checkout खोलते हैं। Lovable की documentation के अनुसार यह default रूप से webhooks सेट नहीं करता: app payment और subscription की स्थिति सीधे Stripe से जाँचता है, और webhooks माँगने पर जोड़े जा सकते हैं। यह भी लिखा है कि price IDs test mode और live mode में अलग होते हैं, इसलिए लाइव जाने के लिए नए चाहिए।

माँगने पर स्थिति जाँचना एक सरल checkout के लिए काम करता है। जब आप subscriptions बेचने लगते हैं, तो आम तौर पर webhooks भी चाहिए, क्योंकि renewals, फ़ेल कार्ड और cancellations तब होते हैं जब आपका यूज़र पेज पर नहीं होता। Stripe की documentation इसे सुरक्षित तरीके से करने के बारे में साफ़ है:

• हर webhook को Stripe-Signature header और अपने endpoint secret से, raw request body पर, verify करें।
• डुप्लिकेट और ग़लत क्रम में आने वाले events की उम्मीद रखें। Process किए गए event IDs दर्ज करें ताकि हर एक एक ही बार handle हो (idempotency)।
• याद रखें कि Stripe live mode में फ़ेल हुई deliveries को तीन दिनों तक दोबारा भेजता है, इसलिए टूटा हुआ endpoint ठीक होने पर कई दिनों के events replay कर सकता है।
• Test और live secrets अलग रखें। एक mode की चीज़ें दूसरे mode में नहीं दिखतीं।

क्या मुझे इसे ख़ुद ठीक करना चाहिए, फ़्रीलांसर रखना चाहिए, या एक टीम लानी चाहिए?

अगर आपके app के गिने-चुने यूज़र्स हैं, कोई payments नहीं और कोई संवेदनशील डेटा नहीं, तो आप ऊपर की table पर Lovable के security scan और Supabase के Security Advisor के साथ ख़ुद काम कर सकते हैं, जो RLS बंद वाली tables और सबको अंदर आने देने वाली policies पकड़ता है। एक दोपहर का यह अच्छा इस्तेमाल है।

एक फ़्रीलांसर या fixed-price rescue sprint किसी जानी-पहचानी, सीमित समस्या के लिए ठीक है: एक टूटा integration, एक audit। उसके लिए वे अक्सर सस्ता विकल्प होते हैं। एक बार का fix आपको अगले छह महीने नहीं देता: टेस्ट, releases, upgrades और ऑफ़िस समय के बाहर का incident। वही लगातार ज़िम्मेदारी हम बेचते हैं: Plutonapps, Lovable apps को production तक ले जाने और उन्हें चलाने में विशेषज्ञ है, और हमारी एजेंसी, फ़्रीलांसर, इन-हाउस भर्ती और सब्सक्रिप्शन की तुलना बताती है कि कौन कब ठीक बैठता है।

लॉन्च के बाद क्या होता है, और on call कौन है?

लॉन्च पर काम बदलता है, रुकता नहीं। किसी को errors पर नज़र रखनी है, security updates लगाने हैं, incidents का जवाब देना है और पिछला तोड़े बिना अगला फ़ीचर ship करना है। हमारे Starter प्लान पर फ़ाउंडर Lovable में prompt करते रहते हैं, और हमारे इंजीनियर हर version को असली प्रोडक्ट में बनाते हैं, हर बदलाव पर regression और visual regression टेस्ट, code review और security checks चलाते हैं, हफ़्ते में दो बार production पर deploy करते हैं, और हर महीने पाँच तक production इमरजेंसी घटनाएँ सँभालते हैं, कामकाजी घंटों के सपोर्ट के साथ। Growth में लगातार deployment और 24/7 सपोर्ट जुड़ता है। जानकारी और कीमतें हमारे pricing पेज पर हैं।