Lovable 2026: छोटे प्रयोग से असली ग्राहकों तक की तैयारी
Lovable में ऐप बनाने से पहले credits, खर्च, डेटा, सुरक्षा और बैकअप समझें। छोटे प्रयोग से ग्राहकों के लिए ऐप तैयार करने की गाइड; हमने ऐप बनाकर नहीं परखा है।
मूल publication 17 अगस्त 2026, व्यापक official-source review 12 सितंबर और scoped update 23 सितंबर 2026 का है। हमने app build, credits purchase, repository connection, security, speed, uptime या support test नहीं किया। Examples proposed exercises हैं, customer results नहीं। Lovable link affiliate है; खरीद पर UseAIVisora को कमीशन मिल सकता है।
अच्छा preview और चलता business अलग सवाल हैं
ऐप का preview बताता है कि आपका विचार स्क्रीन पर कैसा दिखेगा। लेकिन पहला ग्राहक आने के बाद ऐप कौन चलाएगा, यह अलग सवाल है। नीचे की तैयारी-सूची दोनों बातों को अलग रखती है।
यह गाइड उन छोटी टीमों और संस्थापकों के लिए है जिनका काम तय है, तकनीकी जाँच करने वाला व्यक्ति है और बजट सीमित है। इसे तय कीमत में पूरा सिस्टम मिलने, प्रदर्शन साबित होने या बिना देखभाल के ऐप चलने का वादा न समझें। पहले उपयोगी काम चुनें; फिर मालिकाना हक, डेटा वापस पाने, खर्च और ग्राहक की जरूरत को अलग-अलग जाँचें।
Lovable क्या बनाने के लिए है?
Docs natural-language development environment में websites/web apps, interface, backend functions, authentication और integrations बताती हैं। Projects workspaces में रहते और external code repo से जुड़ सकते हैं। यह documented capability है, generated app की आपकी requirements पूरी होने का proof नहीं।
पहले जाना-पहचाना workflow लें: consultant का status portal या operations की stock-request form। पूरे SaaS के हर feature से न शुरू करें। छोटा scope बताता है issue implementation में है या requirement में।
सितंबर update: connected tools की permissions फिर देखें
21 सितंबर changelog में workspace conversations और बिना code edit planning वाला project Chat mode, साथ में centralized permissions आया। 22 सितंबर में managed Parallel research connector आया जिसकी requests Run credits लेती हैं। इसलिए feature build से पहले भी tool access और operating cost जांच का हिस्सा हैं।
Settings → Your account → Preferences → Agent permissions में connector actions के Always allow, Ask each time और Never allow विकल्प हैं। Chat से project creation/editing में केवल पहले दो हैं। Preferences account के साथ workspaces में जाती हैं; personal से client work में जाते समय फिर review करें। Consequential writes में approval और गैरजरूरी connector actions बंद रखना हमारी सलाह है।
ये additions 23 सितंबर 2026 को official docs से देखे गए। Scoped update है, नया hands-on या हर पुराने claim का fresh review नहीं।
छोटे प्रयोग के बाद ऐप जारी करने की तैयारी
ये स्थितियाँ Lovable को दिए गए अंक नहीं हैं। जब तक आपकी टीम अपने ऐप में प्रमाण न देख ले, इन्हें खुले सवाल मानें।
| Gate | क्या evidence चाहिए | स्थिति |
|---|---|---|
| Useful customer task | एक intended user एक defined job पूरा करे और लौटने की वजह बताए। | अपने pilot में जांचना बाकी |
| Operating cost | Build, hosted operation, in-app AI अलग record और workspace balance reconcile। | Usage पर निर्भर |
| Code/data recovery | Synced repo code access है; database/services recovery अलग exercise। | जांचना बाकी |
| Access/security | Actual app permissions/deployment; platform trust page app certification नहीं। | Configuration पर निर्भर |
| Launch ownership | Release accept, incidents handle और pilot stop करने वाला व्यक्ति। | नामित करना जरूरी |
Credits: पूरा workspace budget देखें
Reviewed public pricing FAQ free starting plan में पांच daily build credits, महीने में अधिकतम 30, और monthly Cloud/in-app AI grants बताता था। Paid workspaces building, Cloud और app AI के लिए shared balance इस्तेमाल करते हैं। Plan/activity से consumption/value बदलती है; credits को fixed completed apps में न बदलें। Payment से पहले actual regional offer और workspace देखें।
चार entries रखें: subscription/credits खरीद, changes के समय usage, deployed app की usage और human review/repair time। Provider charges और client fee अलग रखें। US customer वाले भारतीय agency को original billing currency और bill के actual conversion से reconcile करना चाहिए, assumed rate नहीं।
खर्च समझ में न आए, या बार-बार सुधार करने पर भी ऐप के बारे में कुछ नया न सीखें, तो काम रोककर जाँचें। हमने कोई plan नहीं खरीदा और सामान्य ऐप बनाने का खर्च नहीं मापा है।
कोड आपका होने का मतलब पूरा बैकअप होना नहीं
Pricing FAQ third-party rights के अधीन projects, code, stored customer data और generated output users का बताता है। इससे खास project elsewhere restore होना सिद्ध नहीं।
Reviewed Git sync GitHub, GitLab और Bitbucket पर selected branch के साथ two-way sync बताता है। Connection, completed sync और tested restoration तीन अलग अवस्थाएं हैं। पहली से बाकी दो साबित नहीं।
Pilot महत्वपूर्ण होने से पहले exact saved revision पहचानें, अलग permitted environment में code चलाएं और Git के बाहर dependencies लिखें: database contents, uploads, environment variables, domain access, third-party accounts। Recovery notes में live secrets न डालें।
Client material से पहले training-data विकल्प
Lovable के मुताबिक 9 सितंबर 2026 से Free/Pro customer content training में इस्तेमाल हो सकता है जब तक contributor opt out न करे। Builder prompts, attached files और code जैसे inputs/outputs शामिल; docs app end-user data और Business/Enterprise workspace data को default से बाहर बताते हैं।
Free/Pro में Account settings → AI model training के अंदर Use my Lovable content for model training बंद कर सकते हैं। यह individual और आगे के लिए है: collaborators की preferences नहीं बदलतीं, पहले assembled datasets का material नहीं हटता।
Client code/docs से पहले हर contributor की settings और client की service-use permission जांचें। Opt-out approved data-handling agreement का विकल्प नहीं।
Trust page होना ऐप की सुरक्षा जाँच का प्रमाण नहीं
Publicly published apps में /.well-known/trust.html पर automatic trust page documented है। Deployment से जुड़े observed connection, dependency और authorization signals देता है। Announcement इसे certification या automatic compliance से अलग बताता है।
इसे review की शुरुआत मानें। Login screen और database protection setting से यह नहीं पता चलता कि गलत customer दूसरे का record मांग सकता है या नहीं। Authorized test accounts से actual rules चलाकर देखना होगा। यह लेख security certification/legal assessment नहीं।
पहला pilot: project-status portal
काल्पनिक agency में दो roles रखें: client केवल अपना status पढ़े और owner उसे update करे। पहले version में payments, uploads और automated client emails बाहर रखें।
| Gate | Evidence | कब न बढ़ाएं |
|---|---|---|
| Reader value | Invited tester status check पूरा और उपयोगिता बताए। | Page की तारीफ हो, workflow की जरूरत नहीं। |
| Access | Signed-out, wrong-client, owner tests; fictional records। | दूसरे का record पढ़/बदल सके। |
| Cost | Pilot/corrections की reconciled usage। | Charges समझ न आएं या similar task estimate न हो। |
| Recovery | Saved revision + अलग data/dependency recovery record। | केवल repository को backup गिना जाए। |
| Release | Approved version, deployed URL पर फिर checks। | Public app reviewed preview से अलग चले। |
Publishing docs publication को अलग action और pre-publication security review बताते हैं। Deployed result पर अपने acceptance checks दोहराएं। Publish button होने से release ready नहीं।
अमेरिका और भारत में क्या अलग जांचें?
Technical gates वही, project context अलग। US buyer का procurement reviewer terms/data handling approve कर सकता है। Indian agency को उसी customer की जरूरतों के साथ अपनी billing/delivery responsibilities तय करनी हैं। Website खुलने से data residency, payment method या contract suitability न मानें।
भारतीय regional-language pilot में fluent reviewer labels, instructions, errors और लंबे mobile text देखे। US-facing में customer के अपेक्षित terms/workflow लें। ये proposed localization checks हैं, किसी खास integration/legal obligation के Lovable से पूरे होने का दावा नहीं।
पहला user app तक कैसे आएगा?
बड़ी feature list से पहले intended user कैसे पहुंचेगा और successful use क्या होगा तय करें। Existing clients का portal और strangers लाने वाला public tool अलग adoption plan मांगते हैं।
Invitation channel, permitted testers की छोटी group और एक observable activation event रखें। Portal में client का बिना मदद अपना status ढूंढना हो सकता है। Visits, generated pages या demo revenue evidence नहीं। हमने Lovable businesses की acquisition/retention नहीं मापी।
क्या Lovable आजमाएं?
Specific workflow, reviewer और acceptable recovery plan हो तो छोटा pilot उचित है। Usefulness और operation का evidence मिलने तक सीमित रखें। Generated app inspect या failures own करने वाला कोई नहीं तो build बढ़ाने से पहले वह gap हल करें।
दूसरे managed builder और backend guides की अपनी evidence dates हैं; इन्हें current universal recommendation न मानें।
आम सवाल और जवाब
क्या Lovable hands-on test हुआ?
नहीं। Official docs और proposed pilot record हैं; measured quality, billing, speed, security या support results नहीं।
Map US/Indian client में इस्तेमाल कर सकते हैं?
Planning aid के तौर पर हां। User task, language, terms और responsibilities adapt करें। यह regional legal compliance का प्रमाण नहीं।
कोड मेरा है तो क्या पूरा बैकअप भी है?
नहीं। कोड का कौन-सा संस्करण सहेजा है, यह तय करें। डेटा, फाइलें, गुप्त कुंजियाँ और बाहर की सेवाओं की सूची अलग रखें। केवल repository जुड़ी होने से बेहतर प्रमाण यह है कि बैकअप से ऐप सच में वापस चला सकें।
जानकारी के स्रोत
ये मूल लेख के official sources हैं। इनमें से कई पेज English में हैं।