Hostinger AI Builder से वेब ऐप कैसे बनाएँ: Horizons की आसान गाइड
ग्राहक पूछताछ ऐप के उदाहरण, सीमित निर्देश, अनुमतियाँ और प्रकाशन से पहले परीक्षण के साथ AI Builder की प्रक्रिया।
मूल प्रकाशन 1 अगस्त 2026; अपडेट 12 सितंबर 2026; व्यापक तथ्य-जाँच 25 अगस्त 2026। 9 सितंबर को नाम और शुरुआत के विकल्प दोबारा जाँचे गए। 12 सितंबर का बदलाव चार समझाने वाले चरणों और बनावट तक सीमित था, नया उत्पाद परीक्षण नहीं। मौजूदा नाम Hostinger AI Builder है; पुराने Horizons URL को रखा गया है। सहयोगी लिंक से खरीद पर कमीशन मिल सकता है।
छोटा और वापस बदला जा सकने वाला शुरुआती नमूना
यह साफ़ स्वीकार-शर्तों वाला वापस बदला जा सकने वाला नमूना, कैलकुलेटर, निर्देशिका, छोटा पोर्टल या पूछताछ वर्कफ़्लो बनाने वाले फ्रीलांसर के लिए है। संवेदनशील रिकॉर्ड, जटिल अनुमतियाँ, नियमों के अधीन डेटा या बिना समीक्षा वाले भुगतान के साथ जल्दबाजी में लॉन्च न करें। AI को काम बनाने वाला सहायक मानें: पहले योजना, एक बार में एक हिस्सा, हर भूमिका की जाँच और बाहर जाने की योजना।
काम के विवरण से रिलीज़ तक चार पड़ाव
ये काल्पनिक रिकॉर्ड पर प्रस्तावित परीक्षण हैं, पूरी हो चुकी ऐप के नतीजे नहीं। हर पड़ाव पर देखने योग्य परिणाम मिले तभी अगली परत जोड़ें।
| कदम | काम और उदाहरण | कब रुकें |
|---|---|---|
| काम का विवरण | पहले उपयोगकर्ता, मुख्य काम, पन्ने, डेटा और गलती के संदेश लिखें। एक सार्वजनिक फ़ॉर्म और एक मालिक रखें; भुगतान व अपलोड बाहर हों। आगंतुक पूछताछ भेजे; केवल मालिक पढ़े और स्थिति बदले। | ऐप को उपयोगकर्ता के देखे जा सकने वाले काम और अपेक्षित नतीजे में नहीं बता सकते। |
| छोटा रास्ता बनाएँ | Sample Project जैसे काल्पनिक रिकॉर्ड पर फ़ॉर्म और निजी सूची माँगें। बनावट व दिखाई देने वाले लेबल जाँचकर एक सीमित सुधार करें। प्रीव्यू का सफलता संदेश रिकॉर्ड सहेजे जाने का प्रमाण नहीं। | व्यवहार जाँचे बिना असली इंटीग्रेशन या ग्राहक डेटा जुड़ने लगे। |
| खराबी जाँचें | गलत या खाली इनपुट, दोहरा काम, गलत पहुँच, रीफ़्रेश और मोबाइल चौड़ाई जाँचें। दो बार भेजें, सेव होने में बाधा डालें और बिना लॉगिन मालिक का URL खोलें। अपेक्षित और असली नतीजा लिखें। | निजी डेटा खुले या मुख्य काम में इनपुट रिकवरी के बिना खो जाए। |
| रिलीज़ का फैसला | रोकने वाली खराबियाँ ठीक करें, रिकवरी योजना लिखें और मालिक की मंज़ूरी लें। प्रकाशन के बाद असली URL पर HTTPS, फ़ॉर्म और वही परीक्षण दोहराएँ; पुरानी स्थिति लौटाने का जिम्मेदार तय हो। | प्रकाशित ऐप समीक्षित रूप से अलग चले या टीम जरूरी डेटा वापस न ला सके। |
चार बातें याद रखें
- पहले निर्देश से पहले स्वीकार-शर्तें लिखें; केवल दिखावट नहीं, नतीजा जाँचें।
- परतों में बनाएँ: सार्वजनिक हिस्सा, मुख्य काम, डेटा, लॉगिन, सूचनाएँ, खराबी की अवस्थाएँ और डिप्लॉयमेंट।
- काम-आधारित क्रेडिट में सीमित अनुरोध उपयोगी हैं; बार-बार पूरे ऐप का बदलाव महँगा और ऑडिट करना कठिन हो सकता है।
- अंतर्निर्मित बैकएंड आसान है, लेकिन उत्पादन में महत्वपूर्ण डेटा रखने से पहले उसे रखने और बाहर ले जाने का फैसला जरूरी है।
बिल्डर खोलें और दायरा लिखें
hPanel में Websites → Add website → AI Builder → agentic खोलें। शुरुआती विवरण से प्रोजेक्ट शुरू होता है। गाइड अस्थायी डोमेन बताती है; पुराना प्रोजेक्ट Edit website से फिर खोल सकते हैं। 9 सितंबर 2026 को ये विकल्प जाँचे गए थे। खाते और इंटरफ़ेस बदल सकते हैं; पहला निर्देश भेजने से पहले विवरण तैयार करें।
यहाँ मॉडल प्रोजेक्ट सार्वजनिक फ़ॉर्म, सुरक्षित मालिक-दृश्य और स्थिति वाला पूछताछ ट्रैकर है। यही क्रम निर्देशिका, बुकिंग अनुरोध, नतीजे सहेजने वाले कैलकुलेटर या छोटे पोर्टल में अपनाया जा सकता है। यह दस्तावेज़-आधारित योजना है, प्रत्यक्ष उत्पाद ट्यूटोरियल नहीं।
1. एक उपयोगकर्ता और एक काम तय करें
एक पन्ने का विवरण लिखें, ताकि सुंदर स्क्रीन अस्पष्ट उत्पाद न छिपाए और पहले रूप की सीमा साफ़ रहे।
- मुख्य उपयोगकर्ता: उदाहरण के लिए संभावित ग्राहक।
- मुख्य काम: नाम, ईमेल और प्रोजेक्ट का प्रकार देकर पूछताछ भेजना।
- मालिक का काम: पूछताछ देखना और स्थिति बदलना।
- पहले रूप से बाहर: भुगतान, फ़ाइल अपलोड, कई टीमों की अनुमतियाँ और बड़ी मात्रा में इम्पोर्ट।
- सफलता: नई पूछताछ सिर्फ एक बार दिखे और केवल मालिक देख सके।
- हटाने का नियम: मालिक परीक्षण रिकॉर्ड हटा सके।
2. पहला निर्देश सीमित रखें
उदाहरण निर्देश: अकेले सलाहकार के लिए स्क्रीन के अनुसार ढलने वाला ग्राहक-पूछताछ ऐप बनाएँ। आगंतुक नाम, ईमेल, प्रोजेक्ट का प्रकार और छोटा संदेश भेज सकें। निजी मालिक क्षेत्र में भेजे फ़ॉर्म दिखें और स्थिति New, Contacted या Closed में बदले। नमूना डेटा से शुरू करें। भुगतान, सोशल लॉगिन या फ़ाइल अपलोड न जोड़ें। सबके लिए उपयोगी लेबल और स्पष्ट गलती के संदेश रखें।
सजावट से पहले जानकारी की बनावट देखें। सार्वजनिक फ़ॉर्म और निजी हिस्सा अलग हों, और विवरण के बाहर फीचर न आए हों। नीचे के निर्देश प्रस्तावित हैं, जाँचे हुए परिणाम नहीं; हर बदलाव देखकर उसका परीक्षण करें।
| समस्या | क्या निर्देश दें | बाद में क्या जाँचें |
|---|---|---|
| बहुत सारे फीचर | सिर्फ पूछताछ फ़ॉर्म और मालिक की निजी सूची रखें। भुगतान, चैट या अपलोड न जोड़ें। | प्रक्रिया अब भी मूल विवरण से मेल खाती है। |
| मोबाइल पर जगह कम | 390px स्क्रीन के लिए फ़ॉर्म ठीक करें। लेबल दिखें और आड़ा स्क्रॉल न हो। | छोटी चौड़ाई पर फ़ील्ड, संदेश और बटन इस्तेमाल किए जा सकें। |
| दोहरी पूछताछ | सेव करते समय दोबारा भेजना रोकें। गलती होने पर भरे विवरण बचाकर साफ़ परिणाम दिखाएँ। | डबल-क्लिक या सेव विफल होने पर दोहरा रिकॉर्ड या इनपुट का नुकसान न हो। |
| मालिक के रिकॉर्ड खुले | सिर्फ नेविगेशन लिंक न छिपाएँ; रिकॉर्ड और स्थिति बदलना अधिकृत मालिक तक सीमित करें। | बिना लॉगिन और गलत खाते से रिकॉर्ड पढ़ना या बदलना संभव न हो। |
| बड़ा बदलाव काम करता हिस्सा तोड़ता है | केवल बताई खराबी ठीक करें। चल रहे फ़ॉर्म, रास्ते और मालिक की अनुमतियाँ बचाएँ। | मूल स्वीकार-परीक्षण फिर चलाएँ और बदलाव का दायरा देखें। |
3. पहले सार्वजनिक प्रक्रिया जाँचें
लॉगिन या उत्पादन डेटा के बिना फ़ॉर्म जाँचें। एक बार में एक सुधार माँगें। Hostinger AI के परिणाम संभाव्यता-आधारित बताता है; सब कुछ सुधारने का निर्देश असंबंधित काम करते हिस्से बदल सकता है।
- लेबल दिखाई दें और सही इनपुट से जुड़े हों।
- जरूरी फ़ील्ड खाली होने पर कमी साफ़ बताई जाए।
- ईमेल फ़ॉर्मैट की जाँच समझ आए।
- दो बार भेजना रोका जाए।
- सफलता या खराबी का संदेश तकनीकी विवरण न खोले।
- 390px, 768px और डेस्कटॉप पर फ़ॉर्म चले।
- कीबोर्ड फ़ोकस पन्ने के क्रम में जाए।
4. जरूरी डेटा ही जोड़ें
फ़ॉर्म ठीक चले तब सबसे छोटा डेटा मॉडल माँगें: पूछताछ की पहचान, संपर्क फ़ील्ड, सहमति की तारीख और समय, स्थिति, बनने व हटने का समय। शायद आगे काम आए इसलिए अतिरिक्त फ़ील्ड न लें।
अंतर्निर्मित बैकएंड फ़ॉर्म डेटा और फ़ाइलें रख सकता है। आधिकारिक दस्तावेज़ सीधे डेटा एक्सपोर्ट न होने की बात कहते हैं। महत्वपूर्ण रिकॉर्ड लेने से पहले सीमा स्वीकार्य है या नहीं तय करें। डेटा दूसरी जगह ले जाना जरूरी हो तो उत्पादन से पहले Supabase, Firebase या दूसरे बैकएंड की तुलना करें।
5. लॉगिन और अनुमतियाँ अलग हैं
Authentication पहचान की पुष्टि करता है; authorization तय करता है कि उस व्यक्ति को क्या करने की अनुमति है। केवल लॉगिन स्क्रीन रिकॉर्ड नहीं बचाती। नमूना खातों और काल्पनिक डेटा से इनकार वाले सभी परीक्षण पास होने तक असली उपयोगकर्ता न बुलाएँ।
| स्थिति | अपेक्षित परिणाम | कौन-सी खराबी रोकें |
|---|---|---|
| लॉगिन नहीं है | मालिक के रिकॉर्ड नहीं खुलें | रीडायरेक्ट से पहले निजी डेटा दिखना |
| गलत खाता | मालिक का डेटा पढ़ या बदल न सके | अनुमान वाले URL से रिकॉर्ड खुलना |
| मालिक | सिर्फ दस्तावेज़ में तय काम कर सके | जरूरत से अधिक हटाने या एक्सपोर्ट की अनुमति |
| सेशन खत्म | सुरक्षित ढंग से लॉगिन पर लौटे | पुरानी अनुमति से काम जारी रहना |
| पासवर्ड रिकवरी | सत्यापित रिकवरी ही हो | खाते के अस्तित्व का खुलासा या असुरक्षित रीसेट |
6. गुप्त जानकारी बचाकर इंटीग्रेशन
Hostinger भुगतान और बाहरी डेटाबेस जैसी सेवाओं को निर्देश से जोड़ना बताता है। क्रेडेंशियल, API keys और खाते की पहचान चाहिए हो सकती है। गुप्त मान पन्ने की सामग्री, एक्सपोर्ट किए कोड के कमिट या स्क्रीनशॉट में कभी न डालें।
एक बार में एक सेवा जोड़ें। आधिकारिक गाइड, webhook हस्ताक्षर, अनुमत रीडायरेक्ट URL, परीक्षण मोड और खराबी का व्यवहार जाँचें। सफल चेकआउट स्क्रीन से आगे भुगतान में रिफंड, कर, सदस्यता और विवाद के फैसले भी चाहिए।
7. खराबी और एक्सेसिबिलिटी जाँचें
Hostinger पहले संदेश या संस्करण पर लौटना बताता है। बनावट बदलने से पहले स्थिर संस्करण दर्ज करें, ताकि पीछे लौटना सोच-समझकर हो।
- खाली और गलत बनावट वाला इनपुट।
- दोहरा काम।
- धीमा या टूटा कनेक्शन।
- बिना अनुमति वाला रास्ता।
- समाप्त सेशन।
- बाहरी सेवा उपलब्ध न होना।
- लंबे नाम और संदेश।
- स्क्रीन-रीडर लेबल और दिखाई देने वाला फ़ोकस।
- कम गति वाली सामग्री की पसंद।
- हटाने और वापस लाने का व्यवहार।
8. क्रेडिट, होस्टिंग और नवीनीकरण
काम के अनुसार क्रेडिट लगते हैं; जटिल अनुरोध छोटे संपादन से अधिक खर्च कर सकता है। इस्तेमाल की स्क्रीन देखें और आगे सुधार का बजट बनाएँ। होस्टिंग की अवधि, नवीनीकरण रकम और AI से बनाने की पहुँच या होस्टिंग खत्म होने का परिणाम दर्ज करें। पुराने प्रचार दाम के बजाय मौजूदा प्रस्ताव देखें।
9. रिलीज़ सूची के साथ प्रकाशित करें
अंतर्निर्मित SEO या प्रबंधित SSL खोज रैंकिंग, एक्सेसिबिलिटी, सुरक्षा या बिक्री की गारंटी नहीं है।
- नमूना पाठ बदलें, लेकिन परीक्षण खाते अलग रखें।
- canonical URL, शीर्षक, विवरण, favicon और सोशल तस्वीर जाँचें।
- ऐप के लिए उचित निजता, संपर्क और शर्तों की जानकारी दें।
- पहचान व अनुमतियाँ फिर जाँचें।
- अनुमति वाले परीक्षण पते से फ़ॉर्म और जरूरी ईमेल जाँचें।
- डोमेन, HTTPS और मोबाइल व्यवहार देखें।
- एनालिटिक्स और सहमति के विकल्प पुष्टि करें।
- पीछे लौटने और डेटा रखने के कदम लिखें।
- प्रकाशित करें, फिर असली सेवा का छोटा परीक्षण दोहराएँ।
10. बाहर जाने और देखरेख की योजना
प्लान अनुमति दे तो स्वस्थ प्रोजेक्ट का कोड एक्सपोर्ट करके संग्रह जाँचें। Hostinger React/Vite एक्सपोर्ट बताता है, जिसे हाथ से संपादन के बाद आगे निर्देशों के लिए फिर इम्पोर्ट नहीं किया जा सकता। बैकएंड डेटा और इंटीग्रेशन अलग सूची में रखें; कोड पूरा बैकअप नहीं है।
उपयोगकर्ता की पहुँच, सहेजा डेटा, डिपेंडेंसी का व्यवहार, डोमेन व होस्टिंग नवीनीकरण और आधिकारिक उत्पाद बदलाव की नियमित समीक्षा तय करें।
आम सवाल और जवाब
पहले निर्देश में क्या शामिल करें?
पाठक, एक मुख्य परिणाम, जरूरी फ़ील्ड, भूमिकाएँ, डिज़ाइन की दिशा और साफ़ निषेध लिखें। पहला रूप जाँच सकने जितना छोटा रखें।
क्या AI Builder लॉगिन और डेटाबेस बना सकता है?
Hostinger पहचान, डेटा और फ़ाइलों वाला अंतर्निर्मित बैकएंड बताता है। हर भूमिका की अनुमति, रिकवरी, हटाना और निजता फिर भी जाँचनी होगी।
बनाते समय असली ग्राहक डेटा लें?
नहीं। पहुँच, हटाने, डेटा रखने, कानूनी आधार और रिकवरी की मंज़ूरी व परीक्षण तक काल्पनिक रिकॉर्ड लें।
बेकार खर्च हुए क्रेडिट कैसे घटाएँ?
पहले योजना, एक बार में सीमित बदलाव, उपलब्ध सीधा सामग्री संपादन और बड़े बदलाव से पहले स्थिर संस्करण रखें।
क्या यह प्रक्रिया AI Builder में जाँची गई?
नहीं। व्यापक दस्तावेज़ समीक्षा 25 अगस्त 2026, नाम व शुरुआत की जाँच 9 सितंबर और समझाने की बनावट का अपडेट 12 सितंबर को हुआ। इंटरफ़ेस या AI के परिणाम स्वतंत्र रूप से नहीं जाँचे गए।
जानकारी के स्रोत
ये मूल लेख के official sources हैं। इनमें से कई पेज English में हैं।