dApp डेवलपमेंट में क्या शामिल है?
- प्रोडक्ट आवश्यकताएँ और यूज़र फ़्लो
- फ्रंटएंड इम्प्लीमेंटेशन
- वॉलेट कनेक्शन और इंडेक्स किया गया डेटा
dApp डेवलपमेंट एक प्रोडक्ट इंटरफ़ेस को ब्लॉकचेन गतिविधियों और उस डेटा से जोड़ता है जिसकी यूज़र को समझने के लिए ज़रूरत होती है। यह उन टीमों के लिए उपयुक्त है जिनके पास एक स्पष्ट उपयोग मामला है, लेकिन उन्हें अपने कॉन्ट्रैक्ट के आसपास एक सुसंगत एप्लिकेशन लेयर की ज़रूरत है, या उन टीमों के लिए जिन्हें फ्रंटएंड और इंटीग्रेशन को एक साथ विकसित करने की आवश्यकता है।
सुविधाओं की इच्छा-सूची के बजाय यूज़र कार्यों की एक छोटी सूची से शुरुआत करें। प्रत्येक कार्य के लिए, ध्यान दें कि यूज़र क्या देखता है, वे क्या कार्रवाई करते हैं, उसके बाद क्या ऑन-चेन परिणाम होता है और बाद में कौन सी जानकारी दिखाई देनी चाहिए। इससे शुरुआती दौर में ही गायब निर्णय सामने आ जाते हैं: उदाहरण के लिए, क्या किसी स्क्रीन को कनेक्टेड वॉलेट की ज़रूरत है, क्या कोई यूज़र ट्रांज़ैक्शन सबमिट करने से पहले उसकी समीक्षा कर सकता है, और इंटरफ़ेस अपडेटेड रिकॉर्ड को कैसे दर्शाता है।
दायरे में एक नया इंटरफ़ेस, मौजूदा कॉन्ट्रैक्ट से कनेक्शन, इंडेक्सिंग आवश्यकताएँ, या इनका संयोजन शामिल हो सकता है। कॉन्ट्रैक्ट निर्माण एक अलग वर्कस्ट्रीम है जब एप्लिकेशन को नए ऑन-चेन लॉजिक की आवश्यकता होती है; स्मार्ट कॉन्ट्रैक्ट डेवलपमेंट देखें। यदि प्रोडक्ट को व्यापक तकनीकी योजना की आवश्यकता है, तो Web3 डेवलपमेंट से शुरुआत करें।
एक प्रोडक्ट विवरण, उपलब्ध कॉन्ट्रैक्ट इंटरफ़ेस, पसंदीदा चेन, डिज़ाइन संदर्भ और कोई भी मौजूदा फ्रंटएंड तैयार रखें। यदि कुछ इनपुट तैयार नहीं हैं, तो उन्हें तयशुदा आवश्यकताओं के रूप में मानने के बजाय खुले निर्णयों के रूप में पहचानें। AEOTech इन मान्यताओं को लॉन्च स्पेक में रिकॉर्ड करता है ताकि काम शुरू होने से पहले दोनों पक्ष समान दायरे की समीक्षा कर सकें।
dApp फ्रंटएंड को वॉलेट कनेक्शन कैसे संभालना चाहिए?
- कनेक्शन की स्थिति स्पष्ट रूप से दिखाएं
- समीक्षा, सबमिशन और पुष्टिकरण स्थितियों को अलग करें
- उपयोगी रिकवरी पथ प्रदान करें
एक dApp फ्रंटएंड को यूज़र के साइन करने से पहले प्रत्येक वॉलेट-निर्भर कार्रवाई को समझने योग्य बनाना चाहिए। इंटरफ़ेस को डिस्कनेक्टेड वॉलेट, कनेक्टेड अकाउंट, अस्वीकृत अनुरोध और एक ऐसे ट्रांज़ैक्शन के लिए परिभाषित व्यवहार की आवश्यकता है जो सबमिट किया गया है लेकिन अभी तक एप्लिकेशन में प्रतिबिंबित नहीं हुआ है। ये प्रोडक्ट स्टेट हैं जिन्हें डिज़ाइन और परीक्षण करना है, न कि आकस्मिक विवरण जिन्हें अंतिम चरण तक छोड़ दिया जाए।
स्पेक समीक्षा के दौरान, हम स्क्रीन की जाँच अपेक्षित यूज़र जर्नी के विरुद्ध करते हैं। प्रत्येक वॉलेट इंटरैक्शन के लिए, इस बात पर सहमत हों कि पुष्टिकरण से पहले कौन सी जानकारी दिखाई जाती है, यदि यूज़र रद्द करता है तो वे क्या कर सकते हैं, और यदि चयनित अकाउंट या नेटवर्क बदलता है तो इंटरफ़ेस कैसे प्रतिक्रिया करता है। ट्रांज़ैक्शन फ़ीडबैक को विशिष्ट रखें: वॉलेट पर प्रतीक्षा कर रही कार्रवाई को उस कार्रवाई से अलग करें जिसका परिणाम एप्लिकेशन को प्राप्त हो चुका है।
एक उपयोगी हैंडऑफ़ में समर्थित कनेक्शन फ़्लो, आवश्यक अकाउंट और नेटवर्क व्यवहार, यूज़र-सामना करने वाली एरर कॉपी और ट्रांज़ैक्शन के बाद अपेक्षित प्रतिक्रिया शामिल होती है। यदि प्रोडक्ट को सार्वजनिक मार्केटिंग साइट की भी आवश्यकता है, तो इसे Web3 वेबसाइट और लैंडिंग डेवलपमेंट के माध्यम से अलग से तैयार किया जा सकता है। जब टेलीग्राम इंटरफ़ेस प्राथमिक प्रोडक्ट सतह है, तो उस आवश्यकता की तुलना टेलीग्राम बॉट और मिनी ऐप डेवलपमेंट से करें।
इम्प्लीमेंटेशन से पहले, कोई भी मौजूदा डिज़ाइन सिस्टम, वॉलेट आवश्यकताएँ और कॉन्ट्रैक्ट इंटरैक्शन विवरण प्रदान करें। यदि ये अभी भी तय किए जा रहे हैं, तो हम चुपचाप आपके लिए चुनने के बजाय विकल्पों और फ्रंटएंड दायरे पर उनके प्रभाव का दस्तावेजीकरण कर सकते हैं।
डीएपी इंडेक्सिंग योजना में क्या शामिल होना चाहिए?
- प्रत्येक स्क्रीन के लिए आवश्यक डेटा
- एप्लिकेशन इसे कैसे पढ़ता और प्रस्तुत करता है
- ताज़गी की अपेक्षाएँ और खाली स्थितियाँ
इंडेक्सिंग एप्लिकेशन व्यू में प्रासंगिक ब्लॉकचेन गतिविधि को उपयोगी बनाने की योजना है। यह तब मायने रखता है जब किसी प्रोडक्ट को अपने यूज़र कार्यों का समर्थन करने वाले रूप में रिकॉर्ड, गतिविधि या अन्य चेन-संबंधित जानकारी प्रस्तुत करने की आवश्यकता होती है। सही दायरा इंटरफ़ेस से शुरू होता है: उन स्क्रीन और प्रत्येक स्क्रीन को आवश्यक फ़ील्ड की सूची बनाएं, फिर उन ज़रूरतों को उपलब्ध डेटा स्रोतों और कॉन्ट्रैक्ट इवेंट से जोड़ें।
लिखें कि कौन सी जानकारी यूज़र की कार्रवाई के तुरंत बाद दिखाई देनी चाहिए और कौन सी एप्लिकेशन के डेटा को रिफ्रेश करने के बाद दिखाई दे सकती है। परिभाषित करें कि इंटरफ़ेस कैसे व्यवहार करता है जब किसी यूज़र के पास कोई रिकॉर्ड नहीं है, जब कोई परिणाम उपलब्ध नहीं है, या जब प्रदर्शित जानकारी नवीनतम कार्रवाई के साथ तालमेल नहीं बिठा पाई है। यह इम्प्लीमेंटेशन और परीक्षण को एक ठोस लक्ष्य देता है, बिना अप्रलेखित प्लेटफ़ॉर्म व्यवहार के बारे में धारणा बनाए।
इंडेक्सिंग कार्य को स्वामित्व और परिचालन अपेक्षाओं की भी पहचान करनी चाहिए। इस बात पर सहमत हों कि मौजूदा बुनियादी ढाँचे तक पहुँच कौन प्रदान करता है, डेटा मैपिंग की समीक्षा कौन करता है और कॉन्ट्रैक्ट व्यवहार में बदलाव कैसे संप्रेषित किए जाएंगे। यदि प्रोडक्ट कॉन्ट्रैक्ट परिवर्तनों पर निर्भर करता है, तो एप्लिकेशन दायरे को टोकन निर्माण और डिप्लॉयमेंट या प्रासंगिक स्मार्ट कॉन्ट्रैक्ट डेवलपमेंट कार्य के साथ समन्वयित करें।
चैनल मैट्रिक्स एक दृश्य में एप्लिकेशन सतहों और उनकी डेटा आवश्यकताओं को रिकॉर्ड करता है। इसका उपयोग यह जाँचने के लिए करें कि प्रत्येक नियोजित स्क्रीन का एक स्रोत, एक प्रदर्शन नियम और लापता या विलंबित डेटा के लिए एक सहमत व्यवहार है। यह विशेष रूप से तब उपयोगी होता है जब फ्रंटएंड, कॉन्ट्रैक्ट और डीएपी डेवलपमेंट कार्य विभिन्न योगदानकर्ताओं द्वारा संभाले जाते हैं।
dApp डेवलपमेंट प्रोजेक्ट से आपको क्या मिलता है?
- एक समीक्षित दायरा और कार्यान्वयन योजना
- सहमत फ्रंटएंड और इंटीग्रेशन कार्य
- एक हैंडऑफ़ जो बताता है कि क्या वितरित किया गया
डिलीवरेबल्स अनुमोदित दायरे का पालन करते हैं, न कि किसी मानक एक-आकार-सभी-के-लिए-फिट पैकेज का। किसी मौजूदा प्रोडक्ट पर केंद्रित dApp के लिए, इसका मतलब फ्रंटएंड बनाना और वॉलेट कनेक्शन को एकीकृत करना हो सकता है। डेटा-भारी दृश्यों वाले प्रोडक्ट को इंडेक्सिंग वर्कस्ट्रीम की भी आवश्यकता हो सकती है। सटीक संयोजन इम्प्लीमेंटेशन से पहले पुष्टि की जाती है ताकि कार्य की विशिष्ट आवश्यकताओं के विरुद्ध समीक्षा की जा सके।
| कार्य क्षेत्र | दस्तावेजीकरण के लिए दायरे के निर्णय |
|---|---|
| फ्रंटएंड | स्क्रीन, यूज़र कार्य और उत्तरदायी व्यवहार |
| वॉलेट कनेक्शन | कनेक्शन स्थितियाँ और ट्रांज़ैक्शन फ़ीडबैक |
| इंडेक्सिंग | आवश्यक फ़ील्ड, प्रदर्शन नियम और रिफ्रेश अपेक्षाएँ |
| हैंडऑफ़ | वितरित कार्य, ज्ञात मान्यताएँ और अगली कार्रवाइयाँ |
प्रोजेक्ट हैंडऑफ़ को यह स्पष्ट करना चाहिए कि क्या बनाया गया, किन इनपुट का उपयोग किया गया और कौन से निर्णय आपकी टीम के पास रहते हैं। यदि वे प्रोजेक्ट का हिस्सा हैं तो अपने मौजूदा रिपॉजिटरी और डिज़ाइन एसेट जल्दी साझा करें। यह भी पहचानें कि प्रोडक्ट प्रश्नों का उत्तर कौन दे सकता है और इंटरफ़ेस को मंजूरी कौन दे सकता है; विलंबित पहुँच या अनसुलझे निर्णय उस कार्य को रोक सकते हैं जो उन पर निर्भर करता है।
यदि एप्लिकेशन में एक अलग डिजिटल कलेक्टिबल अनुभव शामिल है, तो आवश्यकताओं को NFT कलेक्शन डेवलपमेंट के साथ संरेखित करें। यदि आपको डिलीवरी विकल्पों की तुलना करने में सहायता चाहिए, तो pricing पेज व्यापक सेवा संदर्भ देता है। इस सेवा का अनुमान $5,390 / प्रोजेक्ट से है; अंतिम दायरा आवश्यकताओं और निर्भरताओं की समीक्षा के बाद निर्धारित किया जाता है।
dApp प्रोजेक्ट ब्रीफ से हैंडऑफ़ तक कैसे आगे बढ़ता है?
- इनपुट और दायरे की पुष्टि करें
- समीक्षित आवश्यकताओं के विरुद्ध निर्माण करें
- कार्य रिकॉर्ड करें और रीडआउट के साथ समाप्त करें
एक dApp प्रोजेक्ट एक परिभाषित समीक्षा और वितरण अनुक्रम से गुज़रता है। पहला कार्य यह स्थापित करना है कि पहले से क्या मौजूद है: प्रोडक्ट आवश्यकताएँ, डिज़ाइन सामग्री, कॉन्ट्रैक्ट, पहुँच और अनुमोदन के लिए एक निर्णय-निर्माता। AEOTech फिर निर्भरताओं की पहचान करता है और समीक्षा के लिए प्रस्तावित फ्रंटएंड, वॉलेट और इंडेक्सिंग दायरे को रिकॉर्ड करता है।
लॉन्च स्पेक सहमत सुविधाओं, मान्यताओं और इनपुट के लिए साझा संदर्भ है। एक बार इसकी समीक्षा हो जाने के बाद, इम्प्लीमेंटेशन अनुमोदित कार्य क्षेत्रों का अनुसरण करता है। जब कोई लापता इनपुट किसी यूज़र फ़्लो या इंटीग्रेशन को प्रभावित करता है, तो हम चुपचाप दायरे का विस्तार या पुनर्परिभाषित करने के बजाय प्रश्न उठाते हैं। आपकी टीम कार्य की प्रगति के अनुसार प्रासंगिक इंटरफ़ेस और व्यवहार की समीक्षा करती है, ताकि सुधार उस आवश्यकता से जोड़े जा सकें जिसे वे संबोधित करते हैं।
एक रन लॉग वितरण प्रगति, खुले प्रश्नों और प्रोजेक्ट को प्रभावित करने वाले निर्णयों को रिकॉर्ड करता है। हैंडऑफ़ पर, रीडआउट पूर्ण किए गए कार्य और किसी भी सहमत अनुवर्ती वस्तुओं का सारांश प्रस्तुत करता है। समय-सीमा दायरे, आवश्यक सामग्रियों तक पहुँच, इंटीग्रेशन निर्भरताओं और समीक्षा टर्नअराउंड के आसपास योजनाबद्ध है; हम उन कारकों को समझने के बाद शेड्यूल की पुष्टि करते हैं।
शुरू करने के लिए, एक संक्षिप्त प्रोडक्ट विवरण, पसंदीदा चेन, उपलब्ध कॉन्ट्रैक्ट विवरण, डिज़ाइन या रिपॉजिटरी लिंक और वे यूज़र जर्नी भेजें जिन्हें आप समर्थन देना चाहते हैं। हम उन इनपुट की समीक्षा करेंगे, उन निर्णयों की पहचान करेंगे जिन्हें आपकी मंजूरी की आवश्यकता है और चर्चा के लिए एक प्रोजेक्ट दायरा लौटाएंगे।
टीम को किन dApp डिलीवरी सीमाओं के लिए योजना बनानी चाहिए?
- उपलब्ध दस्तावेज़ीकरण से प्लेटफ़ॉर्म और कॉन्ट्रैक्ट व्यवहार की पुष्टि करें
- सहमत यूज़र फ़्लो के विरुद्ध एप्लिकेशन का परीक्षण करें
- वितरित कार्य को तृतीय-पक्ष परिणामों से अलग करें
एक dApp टीम प्रोजेक्ट दायरे में सहमत इंटरफ़ेस, वॉलेट फ़्लो और डेटा हैंडलिंग को लागू और सत्यापित कर सकती है। हम यह नियंत्रित नहीं कर सकते कि कोई वॉलेट प्रदाता अपना इंटरफ़ेस या अनुमतियाँ बदलता है, कोई नेटवर्क या बाहरी डेटा स्रोत उपलब्ध है, या इंडेक्स की गई जानकारी कब दिखाई देती है। ये व्यवहार प्रभावित कर सकते हैं कि यूज़र क्या देखता है, भले ही एप्लिकेशन कोड निर्दिष्ट के अनुसार वितरित किया गया हो।
अनुमोदन से पहले, उन बाहरी निर्भरताओं की पहचान करें जिन पर प्रोडक्ट निर्भर करता है और तय करें कि जब कोई अनुपलब्ध हो तो इंटरफ़ेस को कैसे प्रतिक्रिया देनी चाहिए। पुष्टि करें कि प्रत्येक निर्भरता का मालिक कौन है, कौन सा परीक्षण वातावरण उपलब्ध है और आपकी टीम समीक्षा के लिए किस साक्ष्य की अपेक्षा करती है। ये निर्णय प्रोजेक्ट को वॉलेट, नेटवर्क या इंडेक्सिंग सेवा द्वारा नियंत्रित व्यवहार का वादा किए बिना देखने योग्य स्वीकृति मानदंड परिभाषित करने देते हैं।
जब आप AEOTech से संपर्क करते हैं, तो प्रोडक्ट विवरण, पसंदीदा चेन, उपलब्ध कॉन्ट्रैक्ट और आपके द्वारा बनाए जाने वाले स्क्रीन या यूज़र जर्नी का एक नमूना शामिल करें। हम उनका उपयोग फ्रंटएंड, वॉलेट कनेक्शन और इंडेक्सिंग कार्य की एक निर्धारित समीक्षा तैयार करने के लिए करेंगे, फिर आपके साथ अगले प्रोजेक्ट निर्णयों की पुष्टि करेंगे।
मूल्य
| सेवा | मूल्य | कोट |
|---|---|---|
| dApp डेवलपमेंट | $5,390 से / प्रोजेक्ट |
USD में शुरुआती मूल्य। कस्टम बंडल और वॉल्यूम डिस्काउंट अनुरोध पर उपलब्ध। भुगतान USDT, USDC, BTC, ETH, SOL, TON या आपके प्रोजेक्ट टोकन में।
यह कैसे काम करता है
- प्रोडक्ट इनपुट साझा करेंप्रोडक्ट विवरण, पसंदीदा चेन, मौजूदा कॉन्ट्रैक्ट विवरण, डिज़ाइन और प्रासंगिक रिपॉजिटरी एक्सेस भेजें। अज्ञात को स्पष्ट रूप से चिह्नित करें।
- दायरे और निर्भरताओं की समीक्षा करेंहम यूज़र जर्नी को फ्रंटएंड, वॉलेट और इंडेक्सिंग कार्य से मैप करते हैं, फिर इम्प्लीमेंटेशन से पहले आवश्यक निर्णयों या पहुँच को चिह्नित करते हैं।
- लॉन्च स्पेक को मंजूरी देंआवश्यकताओं, मान्यताओं और डिलीवरेबल्स की एक साथ समीक्षा करें। कार्य सहमत दायरे के विरुद्ध शुरू होता है।
- निर्माण और समीक्षा करेंहम अनुमोदित कार्य को लागू करते हैं और रन लॉग में प्रगति, प्रश्नों और निर्णयों को रिकॉर्ड करते हैं।
- हैंडऑफ़ प्राप्त करेंरीडआउट आपकी टीम के लिए वितरित कार्य और सहमत अगली कार्रवाइयों का सारांश प्रस्तुत करता है।
अक्सर पूछे जाने वाले प्रश्न
dApp का दायरा तय करने के लिए आपको मुझसे क्या चाहिए?
एक प्रोडक्ट विवरण, वे यूज़र कार्य जिन्हें एप्लिकेशन को समर्थन देना चाहिए, आपकी पसंदीदा चेन, और कोई भी उपलब्ध कॉन्ट्रैक्ट, डिज़ाइन या रिपॉजिटरी भेजें। हमें बताएं कि प्रोडक्ट निर्णयों को कौन मंजूरी दे सकता है। यदि कोई आवश्यकता तय नहीं है, तो इसे खुले के रूप में लेबल करें; इससे हमें पुष्टि किए गए दायरे को उन निर्णयों से अलग करने में मदद मिलती है जो इम्प्लीमेंटेशन को प्रभावित कर सकते हैं।
क्या आप फ्रंटएंड को हमारे पहले से मौजूद कॉन्ट्रैक्ट से जोड़ सकते हैं?
हाँ। उपलब्ध कॉन्ट्रैक्ट विवरण साझा करें और उन यूज़र कार्यों का वर्णन करें जिन्हें फ्रंटएंड को समर्थन देने की आवश्यकता है। हम उन इनपुट के आसपास इंटरफ़ेस और इंटीग्रेशन का दायरा तय कर सकते हैं। यदि कॉन्ट्रैक्ट व्यवहार या दस्तावेज़ीकरण किसी महत्वपूर्ण यूज़र फ़्लो को अस्पष्ट छोड़ देता है, तो हम इम्प्लीमेंट करने के लिए तैयार मानने से पहले समीक्षा के लिए उस प्रश्न की पहचान करेंगे।
dApp को इंडेक्सिंग की आवश्यकता क्यों है?
इंडेक्सिंग एप्लिकेशन व्यू के लिए ब्लॉकचेन-संबंधित जानकारी को व्यवस्थित करने में मदद करता है जिसे इसे प्रस्तुत करने की आवश्यकता होती है। यह आपके प्रोजेक्ट में शामिल है या नहीं, यह यूज़र को आवश्यक स्क्रीन और डेटा पर निर्भर करता है। जिस प्रोडक्ट को इंडेक्स किए गए व्यू की कोई आवश्यकता नहीं है, उसे इस वर्कस्ट्रीम की आवश्यकता नहीं हो सकती है; पहले आवश्यक फ़ील्ड और यूज़र कार्यों की सूची बनाएं, फिर उपयुक्त दृष्टिकोण का दायरा तय करें।
dApp डेवलपमेंट की लागत कितनी है?
प्रोजेक्ट $5,390 / प्रोजेक्ट से शुरू होते हैं। काम शुरू होने से पहले दायरे की समीक्षा की जाती है, क्योंकि फ्रंटएंड, वॉलेट कनेक्शन, इंडेक्सिंग आवश्यकताएँ, मौजूदा सामग्री और इंटीग्रेशन यह निर्धारित करते हैं कि क्या वितरित करने की आवश्यकता है। प्रोजेक्ट-विशिष्ट दायरे के लिए आवश्यकताएँ और उपलब्ध तकनीकी इनपुट भेजें।
dApp प्रोजेक्ट में कितना समय लगता है?
हम सुविधाओं, निर्भरताओं, पहुँच और अनुमोदन प्रक्रिया की समीक्षा करने के बाद समय-सीमा की पुष्टि करते हैं। एक केंद्रित फ्रंटएंड दायरे और एक प्रोजेक्ट जिसमें कॉन्ट्रैक्ट समन्वय या इंडेक्सिंग की भी आवश्यकता होती है, की योजना बनाने के लिए अलग-अलग कार्य होते हैं। उपलब्ध सामग्री प्रदान करें और पहचानें कि निर्णयों की समीक्षा कौन करेगा ताकि शेड्यूल वास्तविक प्रोजेक्ट को प्रतिबिंबित कर सके।
क्या आप गारंटी दे सकते हैं कि कोई वॉलेट या इंडेक्सर हमेशा अपेक्षित परिणाम दिखाएगा?
नहीं। हम उपलब्ध आवश्यकताओं और वातावरण का उपयोग करके सहमत एप्लिकेशन व्यवहार को वितरित और परीक्षण कर सकते हैं, लेकिन वॉलेट प्रदाता अपने स्वयं के इंटरफ़ेस और अनुमतियों को नियंत्रित करते हैं, जबकि नेटवर्क और बाहरी डेटा सेवाएँ उपलब्धता और डेटा समय को नियंत्रित करती हैं। हम उन मामलों के लिए दृश्य स्थितियों को परिभाषित करते हैं ताकि dApp संवाद कर सके कि वह क्या देख सकता है।
जब कोई यूज़र वॉलेट अनुरोध को अस्वीकार करता है तो क्या होना चाहिए?
इंटरफ़ेस को यूज़र को सूचित रखना चाहिए और यह संकेत दिए बिना एक स्पष्ट अगली कार्रवाई प्रदान करनी चाहिए कि अनुरोध सफल हुआ। दायरे की समीक्षा के दौरान, अस्वीकृत अनुरोध, डिस्कनेक्टेड वॉलेट और एक ऐसे ट्रांज़ैक्शन के लिए संदेश और रिकवरी पथ परिभाषित करें जो अभी तक एप्लिकेशन में दिखाई नहीं दिया है। इन व्यवहारों को प्रासंगिक यूज़र-फ़्लो समीक्षा में शामिल किया जाना चाहिए।
अपने प्रोजेक्ट के बारे में बताएं
चार त्वरित प्रश्नों के उत्तर दें और एक मैनेजर एक घंटे के भीतर योजना, समय और मूल्य सीमा भेजेगा। सब कुछ गोपनीय रहता है।
फ़ॉर्म लोड हो रहा है…