Caira आपके कॉन्ट्रैक्ट को 3 क्लिक में रिव्यू कर सकती है:

• सुझाए गए बदलाव और टिप्पणियां सीधे अपनी फ़ाइल में पाएं

• दूसरे पक्ष को भेजने के लिए एक ईमेल सारांश बनाएं

फ्री ट्रायल के लिए साइन अप करने में 30 सेकंड से भी कम समय लगता है। कोई क्रेडिट कार्ड आवश्यक नहीं: अपना फ्री ट्रायल शुरू करें

“यह मेरी मशीन पर काम करता है”: वेब डेवलपर्स को बेहतर कॉन्ट्रैक्ट की आवश्यकता क्यों है

वेब डेवलपमेंट की दुनिया "अपेक्षाओं के अंतर" से परेशान है।

आप ऐसा कोड देते हैं जो स्पेसिफिकेशन से मेल खाता है। क्लाइंट इसे 2014 के iPhone 6 पर खोलता है और चिल्लाता है “यह खराब है!”

आप उनके द्वारा मांगा गया CMS बनाते हैं। वे छह महीने बाद आपको फोन करके मांग करते हैं कि आप उनके द्वारा इंस्टॉल किए गए प्लगइन के कारण आए बग को ठीक करें।

डेवलपमेंट तार्किक है। क्लाइंट इमोशनल होते हैं। आपका कॉन्ट्रैक्ट ही दोनों के बीच का एकमात्र पुल है। इसके बिना, आप लाइफटाइम बिना पैसे के टेक सपोर्ट देने के लिए हामी भर रहे हैं।

यहां वे कानूनी बग दिए गए हैं जिन्हें आपको अपनी 'शर्तों के दस्तावेज' में ठीक करने की आवश्यकता है।

1. “ब्राउज़र कम्पेटिबिलिटी” की बड़ी समस्या

स्थिति: आप एक बेहतरीन React साइट बनाते हैं। यह Chrome और Safari पर बहुत तेज चलती है। क्लाइंट का सीईओ इसे ऑफिस में Internet Explorer 11 पर खोलता है। ग्रिड लेआउट बिगड़ जाता है। वे तब तक भुगतान रोक लेते हैं जब तक कि “यह हर चीज़ पर काम न करने लगे।”

कानूनी सच्चाई:

“हर चीज़ पर काम करना” तकनीकी रूप से असंभव है। किसी विशिष्ट सूची के बिना, एक अदालत “काम करने वाली वेबसाइट” का अर्थ “मानक व्यावसायिक टूल पर काम करना” मान सकती है, जिसमें पुराने ब्राउज़र भी शामिल हो सकते हैं।

समाधान:

एक सपोर्टेड ब्राउज़र क्लॉज।

विशिष्ट रहें। “वेबसाइट को Chrome, Safari, Firefox और Edge के नवीनतम दो संस्करणों पर काम करने के लिए डिज़ाइन किया गया है। पुराने ब्राउज़रों (जैसे, IE11) के साथ कम्पेटिबिलिटी तब तक बाहर रखी गई है जब तक कि स्पेसिफिकेशन में स्पष्ट रूप से सहमति न हो।”

2. एक्सेप्टेंस टेस्टिंग (“लॉन्च” ट्रिगर)

स्थिति: आप साइट पूरी करते हैं। आप लिंक भेजते हैं। “मुझे बताएं कि आपको यह कैसा लगा।”

3 सप्ताह तक सन्नाटा रहता है।

फिर: “क्या हम फ़ॉन्ट बदल सकते हैं?”

फिर 2 सप्ताह तक सन्नाटा।

फिर: “वास्तव में, क्या हम लोगो को हटा सकते हैं?”

आप समय सीमा से 3 महीने आगे निकल चुके हैं और आपको अंतिम 50% का भुगतान नहीं मिला है।

कानूनी सच्चाई:

एक परिभाषित “स्वीकृति अवधि” के बिना, प्रोजेक्ट अधर में लटका रहता है। यह न तो समाप्त होता है और न ही अधूरा रहता है।

समाधान:

एक “डीम्ड एक्सेप्टेंस” क्लॉज।

“क्लाइंट के पास सॉफ्टवेयर का परीक्षण करने के लिए डिलीवरी से 7 दिन का समय है। यदि 7 दिनों के भीतर लिखित रूप में कोई विशिष्ट ‘त्रुटि’ (क्रैश/क्रिटिकल विफलता के रूप में परिभाषित) की रिपोर्ट नहीं की जाती है, तो सॉफ्टवेयर को स्वीकार कर लिया गया माना जाएगा और अंतिम भुगतान देय होगा।”

यह उन्हें इसकी जांच करने, या आपको भुगतान करने के लिए मजबूर करता है।

3. स्कोप क्रीप (“बस एक छोटा सा बदलाव”)

स्थिति: आप 5 पेजों के लिए बजट देते हैं। आधे काम के बाद, क्लाइंट टेक्स्ट भेजता है। यह 12 पेज का है। “मैंने सिर्फ अबाउट पेज को विभाजित किया है, यह कोई बड़ी बात नहीं है, है ना?”

यह एक बड़ी बात है। यह नेविगेशन लॉजिक, मोबाइल मेनू प्रभाव और कंटेंट एंट्री का समय बदल देता है।

समाधान:

“एक वेबसाइट” के लिए बजट देना बंद करें। “काम के दायरे” या स्कोप के लिए बजट दें।

• सख्त डिलिवरेबल्स: “5 x स्टेटिक पेज। 1 x कॉन्टैक्ट फॉर्म।”

बदलाव क्लॉज: “इस स्कोप से बाहर के किसी भी विशिष्ट अनुरोध के लिए हमारी मानक प्रति घंटा दर £[X] पर शुल्क लिया जाएगा। बदलाव स्वीकृत होने तक काम रोक दिया जाएगा।”*

4. कोड का मालिक कौन है? (IP अधिकार)

स्थिति: आप अपने स्टैंडर्ड “स्टार्टर थीम” या हेल्पर फंक्शन्स की लाइब्रेरी का उपयोग करते हैं जिसे आपने सालों पहले लिखा था। क्लाइंट के साथ आपकी अनबन हो जाती है। वे सभी कोड के “पूर्ण कॉपीराइट असाइनमेंट” की मांग करते हैं।

यदि आप सब कुछ सौंप देते हैं, तो आप कानूनी रूप से अगले क्लाइंट के लिए अपनी खुद की स्टार्टर थीम का उपयोग नहीं कर सकते। आपने सिर्फ “घर” नहीं बल्कि उसे बनाने के “औजार” भी बेच दिए।

समाधान:

“कस्टम कोड” और “बैकग्राउंड IP” के बीच अंतर स्पष्ट करें।

“डेवलपर पूरा भुगतान होने पर क्लाइंट को कस्टम डिज़ाइन और टेक्स्ट लेआउट का कॉपीराइट सौंपता है।”*

“डेवलपर सभी ‘बैकग्राउंड IP’ (पुनः प्रयोज्य लाइब्रेरी/फ्रेमवर्क) का स्वामित्व अपने पास रखता है और क्लाइंट को इस वेबसाइट के लिए उनका उपयोग करने का एक स्थायी, गैर-अनन्य लाइसेंस देता है।”*

5. “लाइफटाइम” बग फिक्सिंग

स्थिति: साइट लॉन्च होती है। दो साल बाद, WordPress अपडेट होता है। साइट क्रैश हो जाती है। क्लाइंट फोन करता है: “आपने इसे बनाया है, आप ही इसे ठीक करें।”

समाधान:

एक वारंटी अवधि।

“हम लॉन्च के समय मौजूद बगों को ठीक करने के लिए लॉन्च के बाद 30 दिनों की वारंटी अवधि प्रदान करते हैं। 30 दिनों के बाद उत्पन्न होने वाली या तीसरे पक्ष के अपडेट (प्लगइन/ब्राउज़र परिवर्तन) के कारण होने वाली कोई भी समस्या सशुल्क रखरखाव के अधीन होगी।”

कॉन्ट्रैक्ट रिव्यू आपके दस्तावेज़ीकरण का काम क्यों करता है

आप अपने कोड पर कमेंट लिखते हैं। आपको अपने व्यावसायिक संबंधों पर भी स्पष्टता रखनी चाहिए।

क्रिएटर्स और डेवलपर्स के लिए, IP लाइसेंसिंग और असाइनमेंट के जालों पर हमारी गाइड देखें।

AI कॉन्ट्रैक्ट रिव्यू आपके डेवलपर एग्रीमेंट का विश्लेषण करता है। यह जांचता है कि क्या आपने गलती से “उचित कौशल और देखभाल” के बजाय “उद्देश्य के लिए उपयुक्तता” (एक उच्च कानूनी मानदंड) का वादा तो नहीं किया है। यह सुनिश्चित करता है कि आपकी “स्वीकृति” प्रक्रिया पूरी तरह सुरक्षित है। यह पुराने विवादों के बिना प्रोजेक्ट डिलीट करने और भुगतान प्राप्त करने में आपकी मदद करता है।

अस्वीकरण: इस लेख की जानकारी केवल सामान्य मार्गदर्शन के लिए है और इसे पेशेवर कानूनी, वित्तीय, कर या चिकित्सा सलाह नहीं माना जाना चाहिए।