संक्षेप में जवाब
«टर्नकी» शब्द तैयार नतीजे का अहसास बताता है, तय किया गया काम का दायरा नहीं। यहाँ पढ़िए कि कौन-सी मदें अक्सर कोटेशन से बाहर रहती हैं, दायरे को अनुबंध की भाषा में कैसे लाएँ और हस्ताक्षर से पहले क्या पूछें।
«टर्नकी» एक वादा है, काम का दायरा नहीं
यह मुहावरा निर्माण से आया है: आप चाबी सौंपते हैं, बाद में लौटते हैं और सब कुछ चल रहा होता है। कंपनी की वेबसाइट के कोटेशन में यही शब्द मदों की एक सीमित सूची बन जाता है, और जो उस सूची में नहीं है उसका बिल अलग आता है। वादे और सूची के बीच का यही अंतर लॉन्च से ठीक पहले आने वाले लगभग हर असहज बिल की जड़ है।
आमतौर पर इसमें बेईमानी नहीं होती। स्टूडियो वही गिनता है जिसे गिनना उसे आता है: पेज, लेआउट, फ्रंटएंड, इंटीग्रेशन और परीक्षण। टेक्स्ट, फोटोग्राफी, डोमेन, कॉर्पोरेट मेल, कानूनी पेज और एनालिटिक्स सेटअप सीमा पर खड़े रहते हैं: दोनों पक्ष उन्हें मान लेते हैं और कोई भी उन्हें लिखता नहीं। अनुबंध में मान्यता का कोई अस्तित्व नहीं होता।
इसलिए उपयोगी सवाल यह नहीं है कि टर्नकी वेबसाइट की कीमत क्या है, बल्कि यह कि वह चाबी किन मदों को खोलती है। आगे यही अंतर है — खरीदार आमतौर पर क्या शामिल मानता है, व्यवहार में क्या बाहर रहता है, और काम शुरू होने से पहले दोनों हिस्सों को अनुबंध की भाषा में कैसे लाया जाए।
ग्राहक क्या सुनता है और स्टूडियो किसकी कीमत लगाता है
ग्राहक के दिमाग़ में यह वाक्य कुछ ऐसा पढ़ा जाता है: मैं लोगो देता हूँ और कंपनी के बारे में बताता हूँ, और कुछ हफ़्तों बाद मुझे अपने पते पर चलती हुई वेबसाइट मिलती है — कॉर्पोरेट मेल, तैयार टेक्स्ट, तस्वीरें, काम करता पूछताछ फॉर्म और विज़िट के आँकड़ों के साथ। यह अपेक्षा तर्कसंगत है; सजा-सजाया फ्लैट इसी तरह बिकता है।
स्टूडियो के दिमाग़ में वही वाक्य आमतौर पर इतना ही कहता है: तय संख्या में पेजों का डिज़ाइन और डेवलपमेंट, ग्राहक की दी हुई सामग्री से भराई, और ग्राहक की भुगतान की हुई होस्टिंग पर प्रकाशन। दोनों पाठ ईमानदार हैं। दिक्कत यह है कि हस्ताक्षर से पहले इनमें से कोई भी ज़ोर से कहा नहीं जाता।
इन्हें मिलाने में आधा घंटा लगता है। दोनों पक्ष अलग-अलग लिखें कि स्वीकृति के दिन स्क्रीन पर क्या होगा और उसे किसने बनाया। इन दो सूचियों का अंतर ही आपके भविष्य के अतिरिक्त बिल हैं, जो जल्दी दिख जाते हैं — तब, जब उन पर शांति से बात करने का समय बचा होता है।
वे मदें जो अक्सर कोटेशन से बाहर रह जाती हैं
अपवादों की सूची एक प्रोजेक्ट से दूसरे तक लगभग नहीं बदलती: टेक्स्ट और संपादन, फोटोग्राफी और चित्रण, डोमेन, होस्टिंग, कॉर्पोरेट मेल, एनालिटिक्स और लक्ष्यों का सेटअप, कानूनी पेज, दूसरी भाषाओं में अनुवाद, तथा सोर्स फाइलों और एक्सेस का हस्तांतरण। हर मद अकेले छोटी है; साथ मिलकर वे दूसरा बजट बना देती हैं।
रकम से ज़्यादा मायने समय रखता है। ये बिल शुरुआत में नहीं आते, जब बजट अभी खुला है, बल्कि अंत में आते हैं — जब साइट लगभग तैयार है, लॉन्च की तारीख घोषित है और मोल-भाव करना असहज लगता है। यहीं से यह टिकाऊ अहसास बनता है कि प्रोजेक्ट महँगा हो गया, जबकि कीमत बस अधूरी थी।
समझदारी भरा जवाब यह नहीं कि ऐसा स्टूडियो ढूँढ़ा जाए जहाँ सब कुछ शामिल हो। अगर सचमुच शामिल है, तो उस काम की लागत कीमत के भीतर ही बैठी है, बस आपको दिखती नहीं। समझदारी भरा जवाब है मदों को पहले देख लेना और बाँट देना: कुछ ठेकेदार को, कुछ अपनी टीम को, कुछ दूसरे चरण के लिए टाल देना।
डोमेन, होस्टिंग और मेल: तीन अलग सदस्यताएँ
डोमेन हमेशा के लिए नहीं खरीदा जाता। वह एक अवधि का पंजीकरण है जिसे नवीनीकृत करना पड़ता है, और वह किसी तय स्वामी के नाम दर्ज होता है। अगर वह ठेकेदार के नाम है तो आप अपना ही नाम किराए पर ले रहे हैं। कंपनी के नाम पंजीकरण और रजिस्ट्रार का लॉगिन पहले दिन रखना, एक साल बाद स्थानांतरण से कहीं सस्ता पड़ता है।
होस्टिंग दूसरी सदस्यता है और कॉर्पोरेट मेल तीसरी। अधिकांश खरीदार तीसरी का पता तब लगाते हैं जब वे info@ जैसा पता माँगते हैं और सुनते हैं कि यह अलग बिल वाली अलग सेवा है। तीनों में से कोई भी डेवलपमेंट का हिस्सा नहीं है, फिर भी इनके बिना कंपनी के पास चलती हुई वेबसाइट नहीं होती।
अनुबंध में यह एक तालिका से तय हो जाता है: कौन क्या पंजीकृत करता है, किसके नाम पर, पहला साल कौन भरता है, बिल कहाँ जाता है, और प्रोजेक्ट बंद होने पर सदस्यताओं का क्या होता है। तालिका एक पेज लेती है और बाद के लगभग सारे झगड़े हटा देती है कि ज़िम्मेदारी किसकी थी।
टेक्स्ट और फोटोग्राफी: सबसे आम अतिरिक्त बिल
लेआउट को असली शब्दों से भरना पड़ता है। शब्द न हों तो प्रोजेक्ट रुक जाता है, और आमतौर पर तब रुकता है जब डिज़ाइन स्वीकृत और भुगतान हो चुका होता है। कॉपीराइटिंग अपनी समय-सारणी वाला अलग काम है: बातचीत, पेज की संरचना, ड्राफ्ट, संशोधन और प्रूफ़रीडिंग। यह या तो कोटेशन में है या आपके ज़िम्मे।
फोटोग्राफी का व्यवहार भी वैसा ही है। स्टॉक तस्वीरें पृष्ठभूमि और अमूर्त विचार तो ढक लेती हैं, पर आपका दफ़्तर, उत्पाद और लोग नहीं दिखातीं — और यही चीज़ें पाठक को पेज पर रोकती हैं। शूट एक अलग दिन, अलग बजट और अलग लाइसेंस है: तस्वीरें कहाँ छप सकती हैं, कितने समय तक और किन देशों में।
काम करने वाला समझौता ऐसा दिखता है: ठेकेदार पेजों की संरचना और सवालों की सूची देता है, आप सीधी भाषा में जवाब लिखते हैं, और संपादक उसे प्रकाशन योग्य बनाता है। यह शून्य से लिखने से सस्ता है और इस उम्मीद से ईमानदार है कि लॉन्च से पहले वाले सप्ताहांत में टेक्स्ट अपने आप आ जाएगा।
कानूनी पेज और एनालिटिक्स: वह काम जिसे कोई सूची में नहीं लिखता
प्राइवेसी पॉलिसी सजावटी पेज नहीं है। GDPR.eu की गाइड साफ़ कहती है: प्राइवेसी नोटिस उसी क्षण देना होता है जब डेटा लिया जा रहा हो, संक्षिप्त और सरल भाषा में, और उसमें ठोस बातें होनी चाहिए — आप कौन हैं, डेटा क्यों लेते हैं, किस कानूनी आधार पर, कितने समय रखते हैं और व्यक्ति के पास कौन-से अधिकार हैं।
एनालिटिक्स भी काम है, चेकबॉक्स नहीं। टैग लगा देना काफ़ी नहीं: किसी को तय करना होगा कि पूछताछ किसे गिना जाए, इवेंट सेट करने होंगे, जाँचना होगा कि फॉर्म सचमुच उन्हें भेजता है, और तय करना होगा कि रिपोर्ट कौन और कितनी बार देखेगा। इसके बिना तीन महीने बाद कोई नहीं बता पाता कि साइट काम कर रही है या नहीं।
ये दोनों मदें प्रस्ताव में लगभग कभी नहीं दिखतीं, क्योंकि इनमें से कोई भी «वेबसाइट» जैसी नहीं लगती। इन्हें कोटेशन में साफ़ लिखिए, चाहे शून्य कीमत के साथ और इस टिप्पणी के साथ कि यह ग्राहक करेगा। अनुबंध में लिखा शून्य, गायब मद से कहीं अधिक जानकारी देता है।
गति और सर्च: भावना की जगह जाँचने योग्य मानदंड
«तेज़ साइट» स्वाद है, स्वीकृति का मानदंड नहीं। जाँचने योग्य रूप अलग पढ़ा जाता है: web.dev तीन Core Web Vitals बताता है — LCP, INP और CLS — जिनकी सीमाएँ 2.5 सेकंड, 200 मिलीसेकंड और 0.1 हैं और जिन्हें पेज लोड के 75वें पर्सेंटाइल पर आँका जाता है। ऐसी शर्त अनुबंध में लिखी और जाँची जा सकती है।
सर्च के मामले में अपेक्षा उल्टी दिशा में ठीक करनी होती है। Google Search Central की शुरुआती गाइड कहती है कि अधिकांश साइटें अपने आप खोजी और इंडेक्स में जोड़ी जाती हैं, और साइटमैप भेजना मदद करता है पर अनिवार्य नहीं। यानी «हम इंडेक्स करा देंगे» कोई सेवा नहीं। सेवा है संरचना, गति, मार्कअप और पेज की सामग्री।
पूरी स्वीकृति जाँचने योग्य कथनों की सूची होनी चाहिए: फॉर्म तय पते पर मेल भेजते हैं, वह मेल पहुँचता है, माप सीमाओं के भीतर रहते हैं, पेज फ़ोन पर खुलते हैं, हर पेज का शीर्षक और विवरण है, और एनालिटिक्स पूछताछ दर्ज करता है। बाकी सब स्वाद की बातचीत है, स्वीकृति नहीं।
सोर्स फाइलें और एक्सेस हस्तांतरण: प्रोजेक्ट असल में कैसे खत्म होता है
प्रोजेक्ट लॉन्च से नहीं, हस्तांतरण से खत्म होता है। पूरी सूची छोटी है: डिज़ाइन की सोर्स फाइलें, कोड रिपॉज़िटरी, होस्टिंग और कंट्रोल पैनल का एक्सेस, डोमेन रजिस्ट्रार का अकाउंट, मेल का प्रशासन, एनालिटिक्स प्रॉपर्टी, CMS का एडमिन अकाउंट और सामान्य अपडेट के लिए निर्देश।
अगर इनमें से एक भी सिर्फ़ ठेकेदार के पास रह जाए तो साइट आपकी नहीं है, आप बस उसका उपयोग करते हैं। सोच-समझकर किए गए सेवा अनुबंध में यह ठीक है। ठीक तब नहीं रहता जब यह संयोग से पता चले — ठीक उसी क्षण जब जल्दी ठेकेदार बदलना हो या पेज अपडेट करना हो और एक्सेस आपके पास न हो।
हस्तांतरण में समय लगता है, इसलिए या तो उसका भुगतान हो या वह दायरे में लिखा हो। «सोर्स फाइलों और एक्सेस का हस्तांतरण» नाम की मद सस्ती पड़ती है और हफ़्तों की चिट्ठी-पत्री बचाती है। अच्छी प्रथा यह है कि इसे अलग दस्तावेज़ से स्वीकार किया जाए जिसमें सौंपे गए अकाउंट गिने हों और हर लॉगिन की पुष्टि हो।
दायरे को अनुबंध में कैसे बदलें और हस्ताक्षर से पहले क्या पूछें
अनुबंधित दायरा मोटा दस्तावेज़ नहीं होता। वह तीन छोटी सूचियाँ हैं: क्या शामिल है, क्या बाहर है, और ग्राहक क्या और कब तक देगा। तीसरी सबसे अहम है, क्योंकि वही खिसकती है: टेक्स्ट, तस्वीरें, कंपनी का विवरण, कानूनी जानकारी और संरचना के फ़ैसले लगभग हमेशा ग्राहक की तरफ़ होते हैं।
हस्ताक्षर से पहले के सवाल छोटे हैं। डोमेन किसके नाम है और पहला साल कौन भरता है? कितने पेज का टेक्स्ट शामिल है और उसे कौन लिखेगा? शूट शामिल है और तस्वीरों के अधिकार किसके पास रहेंगे? कानूनी पेज कौन तैयार करेगा? एनालिटिक्स में ठीक-ठीक क्या सेट होगा? बंद करते समय क्या-क्या सौंपा जाएगा?
VITON13 सेंट पीटर्सबर्ग का डिज़ाइन और डेवलपमेंट स्टूडियो है जो दुनिया भर में दूर से काम करता है, और हमारे कुछ काम मानव निर्देशन में एआई के साथ $13–$113 की सीमा में चलते हैं। पर कोई भी आँकड़ा उन मदों की सूची के बिना कुछ नहीं कहता जिन्हें वह कवर करता है। पहले सूची, फिर संख्या — इसी क्रम में बातचीत छोटी रहती है।
व्यावहारिक चेकलिस्ट
- कोटेशन तीन सूचियों में माँगें: शामिल, बाहर, और ग्राहक द्वारा दिया जाने वाला।
- पक्का करें कि डोमेन किसके नाम है और पहला साल कौन भरता है।
- तय करें कि कितने पेज का टेक्स्ट शामिल है और उसे कौन लिखेगा।
- तस्वीरों के अधिकार और उनके उपयोग की अवधि पहले ही तय कर लें।
- कानूनी पेज और एनालिटिक्स सेटअप को अलग मदों के रूप में जोड़ें।
- अकाउंट और सोर्स फाइलों का हस्तांतरण अलग दस्तावेज़ से स्वीकार करें।
सवाल और जवाब
टर्नकी वेबसाइट के प्रस्ताव में आमतौर पर क्या होता है?
आमतौर पर तय संख्या में पेजों का डिज़ाइन और डेवलपमेंट, मोबाइल पर अनुकूलन, फॉर्म का बुनियादी सेटअप, ग्राहक द्वारा दी गई सामग्री भरना और प्रकाशन। इससे आगे सब कुछ उस विशेष कोटेशन पर निर्भर करता है, इसलिए दायरा जानने का भरोसेमंद तरीका मदों की सूची पढ़ना है, वाक्यांश नहीं।
कौन-सी मदें सबसे अधिक बार कोटेशन से बाहर रहती हैं?
टेक्स्ट और संपादन, फोटोग्राफी और तस्वीरों के अधिकार, डोमेन पंजीकरण, होस्टिंग, कॉर्पोरेट मेल, एनालिटिक्स और लक्ष्यों का सेटअप, कानूनी पेज, दूसरी भाषाओं में अनुवाद, तथा सोर्स फाइलों और एक्सेस का हस्तांतरण। हर मद अलग से छोटी लगती है, पर मिलकर वे दूसरा बजट बना देती हैं।
डोमेन और होस्टिंग किसके नाम पर होनी चाहिए?
ग्राहक कंपनी के नाम पर। डोमेन एक अवधि का पंजीकरण है जिसे नवीनीकृत करना पड़ता है, और वह उसी का होता है जिसके नाम दर्ज है। अगर डोमेन और होस्टिंग ठेकेदार के पास हैं तो आप अपना ही पता किसी और की शर्तों पर इस्तेमाल करते हैं, और साल भर बाद स्थानांतरण पहले दिन के सही पंजीकरण से महँगा पड़ता है।
स्वीकृति के समय साइट की गति कैसे जाँचें?
प्रभाव के बजाय मापे जा सकने वाले मानकों से। web.dev तीन Core Web Vitals बताता है — LCP, INP और CLS — जिनकी सीमाएँ 2.5 सेकंड, 200 मिलीसेकंड और 0.1 हैं और जिन्हें पेज लोड के 75वें पर्सेंटाइल पर आँका जाता है। ये मान अनुबंध में लिखे और तय पेजों पर जाँचे जा सकते हैं।
प्रोजेक्ट बंद होते समय क्या-क्या सौंपा जाना चाहिए?
डिज़ाइन की सोर्स फाइलें, कोड रिपॉज़िटरी, होस्टिंग और कंट्रोल पैनल का एक्सेस, डोमेन रजिस्ट्रार का अकाउंट, मेल का प्रशासन, एनालिटिक्स प्रॉपर्टी, CMS का एडमिन अकाउंट और सामान्य अपडेट के लिए छोटी निर्देश-पुस्तिका। इसे सौंपे गए अकाउंट की सूची वाले अलग दस्तावेज़ से स्वीकार करना सबसे आसान रहता है।