एक फ्रीलांस डेवलपर को कैसे हायर करें

अधिकांश असफल विकास परियोजनाएं खराब कोडित नहीं थीं। उन्हें खराब तरीके से निर्दिष्ट किया गया था, गलत संकेत पर हायर किया गया था, और इतनी अधूरी तरह से सौंप दिया गया था कि अगले डेवलपर को फिर से शुरू करना पड़ा। तकनीकी हिस्सा शायद ही कभी वह जगह होता है जहाँ पैसा गायब होता है।

यह एक गैर-तकनीकी खरीदार के लिए अच्छी खबर है, क्योंकि इसका मतलब है कि सबसे महत्वपूर्ण निर्णय वे हैं जिन्हें आप लेने के लिए योग्य हैं। आपको अच्छी तरह से हायर करने के लिए किसी के जावास्क्रिप्ट का आकलन करने की आवश्यकता नहीं है। आपको समस्या का सटीक वर्णन करने, प्रासंगिक सबूतों को पहचानने, ऐसे प्रश्न पूछने में सक्षम होने की आवश्यकता है जिन्हें धोखा देना मुश्किल है, और एक हैंडओवर पर जोर देना है जो आपको चाबियाँ पकड़े हुए छोड़ देता है। यह गाइड इन चारों के माध्यम से चलती है।

तय करें कि आप वास्तव में क्या बना रहे हैं

परिणाम से शुरू करें, तकनीक से नहीं। “मुझे एक ऐप चाहिए” एक ब्रीफ नहीं है; “ग्राहकों को अपने फोन पर एक स्लॉट बुक करने और भुगतान करने की आवश्यकता है, और मुझे कल की बुकिंग एक सूची में देखने की आवश्यकता है” है। दूसरे संस्करण को कोट किया जा सकता है, परीक्षण किया जा सकता है और उस पर बहस की जा सकती है। पहला नहीं किया जा सकता।

किसी से बात करने से पहले, चार बातें लिख लें:

• किया जाने वाला कामएक उपयोगकर्ता को क्या हासिल करने में सक्षम होना चाहिए जो वे आज नहीं कर सकते। प्रति क्षमता एक वाक्य, तकनीकी भाषा के बजाय उपयोगकर्ता की भाषा में।
• अनिवार्य चीजेंकुछ चीजें जिनके बिना निर्माण व्यर्थ है। यदि आपकी सूची में छह से अधिक हैं, तो यह एक इच्छा सूची है, एक विनिर्देश नहीं।
• पहले से क्या मौजूद हैवर्तमान साइट, होस्टिंग, डोमेन, भुगतान प्रदाता, सीआरएम, स्प्रेडशीट। प्रत्येक एकीकरण काम है, और अघोषित एकीकरण वह जगह है जहाँ अनुमान टूटते हैं।
• इसका रखरखाव कौन करता हैसॉफ्टवेयर एक खरीद नहीं है, यह एक प्रतिबद्धता है। अभी तय करें कि क्या आप डेवलपर को बनाए रखेंगे, किसी और को हायर करेंगे, या इसे स्वयं प्रबंधित करेंगे।

एक उपयोगी अनुशासन: पहले संस्करण को सबसे छोटी चीज़ के रूप में वर्णित करें जो वास्तव में उपयोगी होगी। बाकी सब कुछ दूसरी सूची में जाता है। डेवलपर्स पहली सूची को कोट करते हैं; दूसरी सूची वह है जिसे आप पहली सूची के कमाई करने के बाद फंड करते हैं।

आपको किस तरह के डेवलपर की आवश्यकता है

“डेवलपर” में एक दर्जन अलग-अलग ट्रेड शामिल हैं जो एक-दूसरे के बदले नहीं जा सकते। गलत व्यक्ति को काम पर रखना इस प्रक्रिया में सबसे आम और सबसे महंगी श्रेणी की त्रुटि है।

• फ्रंट-एंडजो उपयोगकर्ता देखता और छूता है: लेआउट, इंटरैक्शन, प्रतिक्रियाशीलता, पहुंच। रीडिज़ाइन, मार्केटिंग साइट या मौजूदा सिस्टम पर एक नए इंटरफ़ेस के लिए किराए पर लें। फ्रंट-एंड डेवलपमेंट फ्रीलांसरों को देखें।
• बैक-एंडडेटा, लॉजिक, एपीआई, प्रमाणीकरण, भुगतान। जब बटन दबाने के बाद जो होता है उसमें मूल्य हो तो किराए पर लें। बैक-एंड डेवलपमेंट फ्रीलांसरों को देखें।
• फुल-स्टैकदोनों, एक कार्यशील मानक तक। अधिकांश छोटे निर्माणों के लिए सही विकल्प, क्योंकि दो विशेषज्ञों के बीच समन्वय छोटे पैमाने पर जितना बचाता है उससे अधिक खर्च होता है।
• सीएमएस और प्लेटफॉर्मवर्डप्रेस, शॉपिफाई, वेबफ्लो और इसी तरह के। यदि आपकी आवश्यकता एक मौजूदा प्लेटफॉर्म द्वारा पूरी की जाती है, तो इसे फिर से बनाने के लिए एक कस्टम डेवलपर को किराए पर लेना पैसे जलाना है। वर्डप्रेस डेवलपमेंट और शॉपिफाई डेवलपमेंट देखें।
• मोबाइलनेटिव आईओएस या एंड्रॉइड, या क्रॉस-प्लेटफॉर्म। वेब से वास्तव में एक अलग अनुशासन, इसकी अपनी स्टोर-समीक्षा और रिलीज बाधाओं के साथ। मोबाइल ऐप डेवलपमेंट देखें।
• रखरखाव और सुधारडीबगिंग, अपडेट, प्रदर्शन, सुरक्षा। अक्सर सभी में सबसे अधिक मूल्य वाला किराया, और जिसे खरीदार सबसे लंबे समय तक टालते हैं। वेबसाइट रखरखाव देखें।

यदि आप वास्तव में यह नहीं बता सकते कि आपको किसकी आवश्यकता है, तो वह स्वयं एक छोटा, सस्ता, अच्छी तरह से परिभाषित काम है: कुछ भी शुरू करने से पहले एक अनुभवी डेवलपर को एक छोटी स्कोपिंग बातचीत के लिए भुगतान करें।

व्यक्ति से पहले प्रौद्योगिकी का चयन करना

आपको भाषा चुनने की आवश्यकता नहीं है। आपको एक निर्णय लेने की आवश्यकता है: प्लेटफॉर्म या कस्टम। इस गाइड में किसी भी अन्य विकल्प की तुलना में इसका आपकी कुल लागत पर अधिक प्रभाव पड़ता है।

एक प्लेटफॉर्म बिल्ड — वर्डप्रेस, शॉपिफाई, वेबफ्लो, एक नो-कोड टूल — का मतलब है कि अधिकांश सॉफ्टवेयर पहले से मौजूद है और आप कॉन्फ़िगरेशन, डिज़ाइन और उन हिस्सों के लिए भुगतान कर रहे हैं जो आपके लिए विशिष्ट हैं। यह तेज़, सस्ता और अगले व्यक्ति को सौंपना आसान है, क्योंकि हजारों डेवलपर्स इसे जानते हैं। सीमा यह है कि आप प्लेटफॉर्म की मान्यताओं के भीतर रहते हैं।

एक कस्टम बिल्ड का मतलब है कि सॉफ्टवेयर आपके लिए लिखा गया है। यह बिल्कुल फिट बैठता है, और इसे बनाने और बनाए रखने में कई गुना अधिक खर्च होता है, क्योंकि इसे लिखने वाला व्यक्ति ही इसे जानता है जब तक कि वे इसे दस्तावेज़ित नहीं करते। कस्टम सही जवाब है जब आप जो करते हैं वह उत्पाद है; यह एक ब्रोशर साइट या एक मानक दुकान के लिए गलत जवाब है।

दो व्यावहारिक नियम। पहला, यदि एक मुख्यधारा का प्लेटफॉर्म आपकी आवश्यकता का अस्सी प्रतिशत पूरा करता है, तो वहीं से शुरू करें और लापता बीस के लिए भुगतान करें। दूसरा, जो भी चुना जाए, पूछें कि क्यों — एक डेवलपर जो आपकी आवश्यकताओं के संदर्भ में विकल्प को समझा नहीं सकता है, वह वह चुन रहा है जो उसे पसंद है, न कि वह जो आपको चाहिए। यदि आप एक पूर्ण साइट बिल्ड पर विचार कर रहे हैं, तो हमारी वेबसाइट लागत गाइड बैंड निर्धारित करती है।

एक संक्षिप्त विवरण लिखना जिसे एक डेवलपर उद्धृत कर सके

एक अच्छा तकनीकी संक्षिप्त विवरण छोटा और विशिष्ट होता है। यह डेवलपर को यह नहीं बताता कि कैसे बनाना है; यह उन्हें बताता है कि जब वे समाप्त कर लें तो क्या सच होना चाहिए।

• समस्या, एक पैराग्राफ में। अभी क्या हो रहा है, और यह क्यों स्वीकार्य नहीं है।
• उपयोगकर्ता कहानियां। “एक ग्राहक के रूप में, मैं … कर सकता हूं ताकि …”। इनमें से पांच से पंद्रह एक वास्तविक विनिर्देश है।
• एकीकरण। हर बाहरी सिस्टम का नाम से उल्लेख करें, जिसमें वे भी शामिल हैं जिन्हें आप तुच्छ मानते हैं।
• आप क्या आपूर्ति कर रहे हैं। कॉपी, चित्र, डिज़ाइन, लॉगिन, परीक्षण डेटा। अघोषित अंतराल बिल योग्य घंटे बन जाते हैं।
• बाधाएँ। समय-सीमा, बजट सीमा, होस्टिंग जिस पर आपको रहना होगा, अनुपालन जिसे आपको पूरा करना होगा।
• पूरा होने की परिभाषा। कहाँ पर तैनात किया गया, कैसे परीक्षण किया गया, किस स्तर तक दस्तावेज़ीकृत किया गया, क्या के साथ सौंपा गया।

एक बजट सीमा शामिल करें। खरीदार कम बोली की उम्मीद में इसे रोकते हैं; व्यवहार में यह केवल गलत पैमाने पर लक्षित प्रस्तावों का उत्पादन करता है, और आप यह पता लगाने में एक दौर का पत्राचार खो देते हैं। महान प्रस्ताव प्राप्त करने वाली परियोजना संक्षिप्तता लिखने के लिए हमारी मार्गदर्शिका में एक पूर्ण टेम्पलेट है, और प्रति घंटा बनाम निश्चित मूल्य बताता है कि आपकी संक्षिप्तता किस मूल्य निर्धारण मॉडल के लिए पूछ रही है।

शॉर्टलिस्ट बनाना

तीन से पाँच उम्मीदवारों का लक्ष्य रखें। कम होने पर आपके पास कोई तुलना नहीं होगी; अधिक होने पर आप उनमें से किसी का भी ठीक से मूल्यांकन नहीं कर पाएंगे।

खोजने के लिए दो दिशाएँ हैं। यदि आपका काम अच्छी तरह से परिभाषित है और आप कुछ विशिष्ट खरीदना चाहते हैं तो काम से शुरू करें — वेबसाइट विकास, सॉफ्टवेयर विकास या वेब अनुप्रयोगों के तहत निश्चित-मूल्य लिस्टिंग ब्राउज़ करें, या वेब डिज़ाइन, वर्डप्रेस डेवलपर्स, मोबाइल ऐप विकास या शॉपिफाई विशेषज्ञों पर मार्केटप्लेस द्वारा।

यदि काम पर चर्चा की आवश्यकता है तो व्यक्ति से शुरू करें। अनुशासन या उपकरण द्वारा डेवलपर्स को ब्राउज़ करें — रिएक्ट, वर्डप्रेस, पीएचपी, पायथन या वेबफ्लो — या संक्षिप्तता पोस्ट करें और प्रस्तावों को आपके पास आने दें। Zinn Hub पर, एक परियोजना पोस्ट करना मुफ्त है, और आप इसे एक विशिष्ट क्षेत्र जैसे वेबसाइट विकास, बैक-एंड विकास या मोबाइल ऐप विकास पर निर्देशित कर सकते हैं।

प्रासंगिकता पर कड़ी और बाकी सब पर हल्की फ़िल्टरिंग करें। एक डेवलपर जिसने आपके जैसी तीन चीजें भेजी हैं, वह एक अलग डोमेन में दोगुने अनुभव वाले डेवलपर को लगभग हर बार हरा देता है।

एक डेवलपर पोर्टफोलियो कैसे पढ़ें

आप किसी के कोड का ऑडिट नहीं कर सकते, और आपको इसकी आवश्यकता भी नहीं है। यदि आप जानते हैं कि क्या देखना है तो एक पोर्टफोलियो अभी भी आपको बहुत कुछ बताता है।

• लाइव लिंक खोलें। एक स्क्रीनशॉट कुछ भी साबित नहीं करता है। अपने फोन पर साइट लोड करें, इसका उपयोग करें, इसे तोड़ें। आज जो कुछ भी टूटा हुआ था, वह टूटा हुआ ही हस्ताक्षरित था।
• अपनी जैसी समस्याओं की तलाश करें। एक ही उद्योग नहीं — एक ही आकार। एक बुकिंग प्रवाह एक बुकिंग प्रवाह है चाहे वह बाल कटवाने या हेलीकॉप्टर बेचता हो।
• जांचें कि उन्होंने क्या किया। टीम परियोजनाओं पर, पूछें कि उनके कौन से हिस्से थे। “मैंने इस पर काम किया” का मतलब बहुत कुछ या बहुत कम हो सकता है।
• बुनियादी बातों का स्वयं परीक्षण करें। क्या पेज जल्दी लोड होता है? क्या यह फोन पर काम करता है? क्या फॉर्म कीबोर्ड के साथ उपयोग करने योग्य हैं? ये शिल्प संकेत हैं जिन्हें एक गैर-तकनीकी खरीदार पूरी तरह से पढ़ सकता है।
• समीक्षाओं को साक्ष्य के एक निकाय के रूप में पढ़ें। एक शानदार समीक्षा शोर है। कई में एक पैटर्न, विशेष रूप से संचार और समय-सीमा के बारे में, संकेत है। Zinn Hub पर समीक्षाओं के लिए एक पुष्ट खरीद की आवश्यकता होती है।
• पूछें कि क्या गलत हुआ। “मुझे एक ऐसी परियोजना के बारे में बताएं जो खराब हो गई” का सबसे मजबूत जवाब एक विशिष्ट, अप्रिय, अच्छी तरह से विश्लेषण की गई कहानी है। केवल सुचारू परियोजनाओं वाले डेवलपर जैसी कोई चीज नहीं है।

इसके एक व्यवस्थित संस्करण के लिए, हमारी 12-चरणीय फ्रीलांसर वीटिंग चेकलिस्ट के माध्यम से काम करें।

किराए पर लेने से पहले पूछने वाले प्रश्न

लक्ष्य किसी को पकड़ना नहीं है। यह सुनना है कि कोई कैसे सोचता है जब जवाब पूर्वाभ्यास नहीं किया जाता है।

• पिछले बिल्ड के बारे में बताएं“मुझे इनमें से किसी एक प्रोजेक्ट और आपके द्वारा किए गए ट्रेड-ऑफ के बारे में बताएं।” एक अच्छा डेवलपर उस चीज़ का नाम बताएगा जिसे उन्होंने न करने का विकल्प चुना और क्यों। बिना ट्रेड-ऑफ के शब्दजाल एक चेतावनी संकेत है।
• आपको यहां क्या चिंता हैपूछें कि आपकी संक्षिप्त जानकारी का सबसे जोखिम भरा हिस्सा क्या है। जो कोई कहता है “कुछ नहीं, यह सीधा है” उसने इसे ठीक से नहीं पढ़ा है।
• क्या गायब है“आपको मुझसे क्या चाहिए जो मैंने प्रदान नहीं किया है?” मजबूत उम्मीदवार इसका तुरंत और विस्तार से जवाब देते हैं।
• मैं प्रगति कैसे देखूंगाएक स्टेजिंग लिंक, एक साप्ताहिक अपडेट, एक साझा बोर्ड। कोई भी जवाब ठीक है; कोई जवाब नहीं, यह ठीक नहीं है।
• लॉन्च के बाद क्या होता हैबग विंडो, सपोर्ट शर्तें, दस्तावेज़। इसे शुरू करने से पहले सहमत हों, न कि जब कुछ टूट जाए।
• कोड का मालिक कौन हैसीधे पूछें। जवाब आपको होना चाहिए, डिलीवरी पर, लिखित रूप में, इसे चलाने के लिए आवश्यक सब कुछ सहित।

प्रतिबद्ध होने से पहले परीक्षण करें

एक खरीदार के लिए उपलब्ध सबसे सस्ता बीमा एक बड़े काम से पहले एक छोटा भुगतान वाला काम है। एक अवैतनिक परीक्षण नहीं, जिसे अच्छे फ्रीलांसर अस्वीकार करते हैं और जो आपको यह नहीं बताता कि जब पैसे शामिल होते हैं तो कोई व्यक्ति कैसा व्यवहार करता है — एक वास्तविक, छोटा, भुगतान वाला कार्य।

एक अच्छा परीक्षण कार्य प्रतिनिधि, आत्मनिर्भर और एक बैठक में समाप्त होने वाला होता है: एक विशिष्ट बग को ठीक करें, एक पृष्ठ को प्रतिक्रियाशील बनाएं, एक फ़ॉर्म जोड़ें और उसे कनेक्ट करें, एक धीमे पृष्ठ में सुधार करें। आप वास्तव में कोड का आकलन नहीं कर रहे हैं। यह है कि क्या उन्होंने शुरू करने से पहले एक स्पष्टीकरण प्रश्न पूछा, क्या उन्होंने वह वितरित किया जो पूछा गया था न कि जो उन्होंने पसंद किया, क्या उन्होंने समझाया कि उन्होंने क्या किया, और क्या उनके द्वारा दिया गया समय-सीमा वही समय-सीमा थी जो आपको मिली।

Zinn Hub पर प्राकृतिक प्रारूप एक माइक्रो Zinn है — $5, $10, $15 या $20 पर एक निश्चित मूल्य वाला कार्य। बग फिक्स और छोटे कोड कार्य या वेबसाइट बग फिक्स और ट्वीक ब्राउज़ करें, या $20 माइक्रो Zinns के साथ एक कीमत से शुरू करें। प्रतिबद्ध होने से पहले एक फ्रीलांसर का परीक्षण कैसे करें पर हमारी मार्गदर्शिका बताती है कि परीक्षण को कैसे संरचित और न्याय किया जाए।

इसकी लागत क्या है और भुगतान कैसे करें

विकास मूल्य निर्धारण किसी भी अन्य फ्रीलांस श्रेणी की तुलना में अधिक भिन्न होता है, क्योंकि काम अधिक भिन्न होता है। जो कुछ भी आता है वह पूरे काम के लिए विशिष्ट बाजार बैंड हैं, न कि Zinn Hub की कीमतें, और हर फ्रीलांसर अपनी खुद की निर्धारित करता है।

• छोटा कार्य

  $200 से कम

  एक बग फिक्स, एक प्लगइन संघर्ष, एक फ़ॉर्म, एक स्पीड पास, एक मौजूदा बिल्ड पर एक छोटी सुविधा। निश्चित मूल्य वाले कार्य के रूप में खरीदना सबसे अच्छा है।

• मानक बिल्ड

  $500–$2,000

  एक प्लेटफ़ॉर्म-आधारित साइट या दुकान: थीम कॉन्फ़िगरेशन, कई पेज टेम्प्लेट, फ़ॉर्म, बुनियादी एकीकरण, लॉन्च।

• उन्नत

  $2,000–$8,000

  कस्टम कार्यक्षमता, खाते और लॉगिन, भुगतान, तृतीय-पक्ष एकीकरण, या खरोंच से लागू एक bespoke डिज़ाइन।

• आवेदन

  $8,000+

  एक वास्तविक सॉफ्टवेयर उत्पाद: बहु-भूमिका प्रणाली, डैशबोर्ड, मोबाइल ऐप, सार्थक बैक-एंड लॉजिक और चल रही इंजीनियरिंग के साथ कुछ भी।

लागत दायरे, जटिलता और अनुभव के अनुसार भिन्न होती है। एक उद्धरण की सत्यता की जांच करने के लिए बैंड का उपयोग करें न कि एक टैरिफ के रूप में — यदि कोई संख्या आपके संक्षिप्त विवरण से दो बैंड दूर है, तो वह अंतर बातचीत के लायक है।

Zinn Hub पर, हर Zinn की कीमत उसके Zinner द्वारा तय की जाती है, खरीदार कोई प्लेटफॉर्म शुल्क नहीं देते हैं, और सभी कीमतें USD में होती हैं, जिसमें आपकी अपनी मुद्रा में अनुमानित समकक्ष दिखाया जाता है। एक ऑर्डर का भुगतान और सुरक्षा एक ही पूरी राशि के रूप में की जाती है; कोई चरणबद्ध या मील का पत्थर जारी नहीं होता है, इसलिए एक चरणबद्ध निर्माण को अलग-अलग ऑर्डर के रूप में रखा जाता है या आपके प्रोजेक्ट ब्रीफ में अलग-अलग मूल्य वाले चरणों के रूप में सहमत किया जाता है। एक प्लेटफॉर्म प्रोटेक्टेड Zinner चुनें और ऑर्डर पूरा होने तक आपका भुगतान Zinn Hub द्वारा रखा जाता है; कोई भी रिफंड आपके Zinn Wallet में USD में पूरी तरह से जमा किया जाता है। जो Zinners अपने PayPal या Stripe खाते को जोड़ते हैं, उन्हें चेकआउट पर सीधे भुगतान किया जाता है।

स्वामित्व, पहुंच और हस्तांतरण

यह वह खंड है जिसे खरीदार छोड़ देते हैं और बाद में पछताते हैं। काम शुरू होने से पहले यह सब लिखित में सहमत हों, क्योंकि डिलीवरी के बाद आपके पास कोई लाभ नहीं बचता है।

• आपके नाम पर खाते। डोमेन, होस्टिंग और कोई भी तृतीय-पक्ष सेवा आपके नाम पर पंजीकृत होनी चाहिए, जिसमें डेवलपर को एक उपयोगकर्ता के रूप में जोड़ा गया हो। कभी भी इसका उल्टा नहीं।
• डिलीवरी पर कोड का स्वामित्व। स्पष्ट रूप से बताएं कि अंतिम भुगतान पर काम आपका है जिसका उपयोग, संशोधन और कहीं और ले जाया जा सकता है। किसी भी तृतीय-पक्ष घटकों के बारे में उनके अपने लाइसेंस के साथ पूछें।
• रिपॉजिटरी एक्सेस। भले ही आप इसे कभी न खोलें, आपको इसे अगले डेवलपर को देने में सक्षम होना चाहिए।
• क्रेडेंशियल, वे सभी। एडमिन लॉगिन, एपीआई कुंजी, डेटाबेस एक्सेस, डिप्लॉयमेंट एक्सेस — अंतिम भुगतान से पहले स्थानांतरित और काम करने की पुष्टि की गई।
• दस्तावेज़ीकरण। कैसे डिप्लॉय करें, चीजें कहां रहती हैं, और अगर यह टूट जाए तो क्या करें, इस पर एक छोटा लिखित नोट। एक पृष्ठ पर्याप्त है; कुछ भी नहीं पर्याप्त नहीं है।
• एक बग विंडो। लॉन्च के बाद की एक परिभाषित अवधि जिसमें वास्तविक दोषों को बिना किसी अतिरिक्त लागत के ठीक किया जाता है। तीस दिन एक सामान्य, उचित मांग है।

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

गलतियाँ जो विकास परियोजनाओं को डुबो देती हैं

• ब्रीफ मौजूद होने से पहले काम पर रखना। विनिर्देश में बिताया गया हर घंटा बिल्ड और रीवर्क में कई बचाता है। इस सूची में और कुछ भी इतना मायने नहीं रखता।
• केवल कीमत पर चुनना। सबसे कम उद्धरण अक्सर वह होता है जिसने सबसे कम समझा, और अंतर परिवर्तन अनुरोधों के रूप में सामने आता है।
• चुपचाप स्कोप जोड़ना। बिल्ड के दौरान छोटे अनुरोध ही हैं कि निश्चित कीमतें विवादों में कैसे बदल जाती हैं। उन्हें बैच करें, उनकी कीमत तय करें, उन पर निर्णय लें।
• कोई स्टेजिंग वातावरण नहीं। काम की समीक्षा केवल तभी करना जब वह लाइव हो, यह है कि एक टूटी हुई साइट ग्राहकों द्वारा खोजी जाती है न कि आपके द्वारा।
• मोबाइल चेक छोड़ना। आपके अधिकांश आगंतुक फोन पर हैं। आपने जिस पर नहीं खोला है, उसे कुछ भी स्वीकृत न करें।
• हस्तांतरण को अंत तक छोड़ना। एक्सेस और स्वामित्व पर सहमत होने का क्षण पहले कमिट से पहले है, न कि अंतिम चालान के दौरान।
• कोई रखरखाव योजना नहीं। सॉफ्टवेयर सड़ जाता है। पहले दिन से अपडेट, बैकअप और सुरक्षा के लिए बजट बनाएं, या बाद में बचाव के लिए भुगतान करें।
• चेतावनी संकेतों को अनदेखा करना। अस्पष्ट उत्तर, छोटी समय-सीमाओं का चूकना और प्लेटफ़ॉर्म के बाहर भुगतान करने का दबाव, ये सभी सामान्य फ्रीलांसर घोटालों के लिए हमारी मार्गदर्शिका में शामिल हैं।

यदि आप अभी भी यह तय कर रहे हैं कि क्या फ्रीलांसर ही सही रास्ता है, तो फ्रीलांसर बनाम एजेंसी एक छोटे व्यवसाय के निर्माण के लिए दोनों की ईमानदारी से तुलना करता है।