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. "लाइफटाइम" बग फिक्सिंग

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

समाधान:

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

"हम लॉन्च के समय मौजूद बग्स को ठीक करने के लिए 30-दिन की वारंटी अवधि प्रदान करते हैं। 30 दिनों के बाद उत्पन्न होने वाली या तीसरे पक्ष के अपडेट के कारण होने वाली समस्याएं बिल योग्य रखरखाव के अंतर्गत आती हैं।"

अनुबंध की समीक्षा आपका प्रलेखन क्यों है

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

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

एआई अनुबंध समीक्षा आपके डेवलपर समझौते का विश्लेषण करती है। यह सुनिश्चित करती है कि आपका स्वीकृति प्रवाह सुरक्षित है। यह विरासत के कर्ज के बिना परियोजना को पूरा करने और भुगतान पाने में आपकी मदद करता है।

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