एक ग्राहक ने मुझे 2021 में फोन किया, उसकी आवाज़ में असली घबराहट थी। उसने चौदह महीनों में £140,000 खर्च करके एक कस्टम इनवॉयसिंग प्लेटफ़ॉर्म बनाया था। उसकी डेव टीम ने शायद 60% स्पेक शिप किया था। और कहीं महीने ग्यारह के आसपास, उसने खोजा कि Invoice Ninja मौजूद है, ओपन-सोर्स है, और जो उसे चाहिए उसका 90% बॉक्स से ही करता है। बिना कोई खर्च के।
मुख्य सीख: SaaS खरीदते रहें जब तक सबस्क्रिप्शन टैक्स, डेटा ओनरशिप या वर्कफ़्लो मेल न खाना वाकई समस्या न बन जाए; कस्टम बनाएँ जब वह टूल आपके बिज़नेस की जीत का मूल हो।
यह कॉल मुझे थोड़ा सताता है। क्योंकि सच का जवाब यह है: मैंने भी उलटी गलती की है। Seahawk के पास 2019 में एक प्रोजेक्ट था जहाँ हमने आठ महीने पाँच अलग-अलग SaaS टूल्स को सिलना गया, Airtable, Zapier, Typeform, HubSpot, और एक कस्टम Webflow CMS, एक क्लायंट वर्कफ़्लो को मैनेज करने के लिए जो, पीछे मुड़कर देखने पर, एक £15,000 की कस्टम बिल्ड ने साफ़-साफ़ और स्थायी तरीके से हल कर दिया होता। हम महीने के आखिर तक कुल सदस्यताओं में लगभग £900/महीना दे रहे थे। तीन साल के लिए गणित करो।
कोई भी चरम अपने आप सही नहीं है। और जो भी तुम्हें एक साफ़ नियम बेच रहा है, "हमेशा बनाओ", "कभी मत बनाओ", कोई चीज़ बेच रहा है। तो यहाँ वह असली ढाँचा है जो मैं इस्तेमाल करता हूँ जब कोई संस्थापक मेरे साथ बैठता है और यह सवाल पूछता है।
---
पहले, स्वीकार करो कि तुम असल में क्या फैसला कर रहे हो
यह कोई तकनीकी निर्णय नहीं है। सच कहूँ तो नहीं। यह एक व्यावसायिक निर्णय है जो तकनीकी कपड़ों में तैयार किया गया है।
जब तुम कहते हो "क्या मुझे बनाना चाहिए या खरीदना चाहिए?", जो तुम असल में पूछ रहे हो वह यह है: मेरे उत्पाद में अंतर कहाँ रहता है? अगर जो चीज़ तुम बनाने पर विचार कर रहे हो वह तुम्हारे प्रतिस्पर्धात्मक लाभ के लिए मूल है, जिसका कारण ग्राहक तुम्हें उनके ब्राउज़र के अगले टैब पर चुनेंगे, तो बनाना शायद समझदारी है। अगर यह बुनियादी ढाँचा, प्रशासन, या सामान्य कार्यप्रणाली है, तो खरीदना लगभग निश्चित रूप से असल शर्तों में सस्ता है।
मैं संस्थापकों से पहले एक सवाल पूछता हूँ: क्या आपके यूज़र्स इस चीज़ को कभी देखेंगे? अगर जवाब हाँ है और यह किसी सार्थक तरीके से उनके अनुभव को आकार देता है, तो इसे बनाना शायद लायक है। अगर यह बैक-ऑफिस, ऑपरेशनल, या आंतरिक है, तो बनाने के लिए बार बहुत ऊँचा होना चाहिए।
---
निर्माण की वास्तविक लागत (लोग इसका बुरी तरह अनुमान लगाते हैं)
मैं सीधे कहता हूँ। कस्टम विकास आपके सोचने से ज़्यादा खर्च करता है, जो आपको बताया जाता है उससे अधिक समय लेता है, और चल रहे रखरखाव की आवश्यकता होती है जिसका किसी ने बजट नहीं बनाया।
संस्थापक असल में क्या कीमत में डालना भूलते हैं
- रखरखाव और होस्टिंग। एक बार की बात नहीं। आप हुक पर हमेशा के लिए हैं जब तक आप चीज़ को सूर्यास्त नहीं करते।
- सुरक्षा पैच। एक SaaS विक्रेता यह आपके लिए संभालता है। आप इसे बनाते हैं, आप इसके मालिक हैं, 2 बजे के अलर्ट सहित।
- नए डेवेलपर्स को ऑनबोर्ड करना। अगर आपका लीड इंजीनियर चला जाता है, तो अगले व्यक्ति को आपके कोडबेस को सीखना होता है। वह बिलेबल समय के हफ्तों हैं।
- फीचर क्रीप। स्टेकहोल्डर्स एक कस्टम टूल देखते हैं और मानते हैं कि यह सबकुछ कर सकता है। स्कोप बढ़ता है। लागतें इसके पीछे चलती हैं।
एक रफ रूल जो मैं इस्तेमाल करता हूँ: अपने शुरुआती डेव एस्टीमेट को लें, यथार्थवादी डिलीवरी के लिए 1.6 से गुणा करें, फिर उस नंबर का 20% सालाना मेंटेनेंस के लिए जोड़ें। अगर ये नंबर अभी भी बिजनेस केस को सपोर्ट करते हैं, तो बढ़िया। अगर नहीं, तो आपके पास आपका जवाब है।
ईमानदारी से, Standish Group की CHAOS Report दशकों से दिखा रही है कि सॉफ़्टवेयर प्रोजेक्ट्स अपने बजट को चौंकाने वाली दर से अतिक्रमण करते हैं। संख्या लगभग 45-50% प्रोजेक्ट्स के आसपास होती है जो "चुनौतीपूर्ण" हैं या बिल्कुल असफल हैं। यह कभी न बनाने का कारण नहीं है, यह साफ़-साफ़ आँखों के साथ जाने का कारण है।
---
SaaS की असली लागत (यह भी कम आंकी गई है, बस अलग तरीके से)
SaaS सस्ता दिखता है जब तक वह नहीं रहता।
वह £49/महीने की योजना जो साल की शुरुआत में उचित लग रही थी, उसे साल तीन तक £490/महीने में बदलने की अजीब आदत है, जब आप एक उच्च टायर पर हो, आपने सीटें जोड़ दी हों, और विक्रेता ने एक "मूल्य पुनर्गठन" किया हो (पढ़ें: बढ़ोतरी)। मैंने इसे Salesforce, Intercom, और Mixpanel पर ग्राहकों के साथ होते देखा है। यह दुर्भावनापूर्ण नहीं है। यह बस SaaS अर्थशास्त्र कैसे काम करता है।
फाउंडर्स तीन SaaS जालों में फंसते हैं
- Vendor lock-in। आपका डेटा उनके format में है, उनके schema में, उनके export flow में। छोड़ना दर्दनाक है और कभी-कभी effectively असंभव है significant data engineering work के बिना।
- Franken-stack जटिलता। पाँच टूल जो Zapier के माध्यम से कुछ-कुछ एकीकृत होते हैं, एक सिस्टम नहीं है। यह एक दायित्व है। एक API का अवमूल्यन और चीजें टूटने लगती हैं।
- सदस्यता में रिसाव। कोई भी अपने टूल स्टैक की सालाना जांच नहीं करता। उन्हें करना चाहिए। मैंने पिछले साल एक 12-व्यक्ति एजेंसी के लिए एक ऑडिट चलाया और £3,200/माह SaaS पाया जिसे वे या तो उपयोग करना बंद कर चुके थे या प्रत्येक के लिए एक फीचर के लिए उपयोग कर रहे थे।
कहा जा रहा है, सामान्य कार्यों के लिए, SaaS लगभग हमेशा सही विकल्प है। ईमेल डिलीवरी? Postmark या SendGrid। पेमेंट्स? Stripe, जाहिर है। Auth? Auth0 या Clerk। 2024 में कोई भी अपना खुद का भुगतान प्रोसेसर नहीं बनाना चाहिए।
---
एक फ्रेमवर्क जो वास्तव में काम करता है
ठीक है। मैं इसे कैसे सोचता हूँ, यह बताता हूँ। चार सवाल, क्रम में।
सवाल 1: क्या यह एक प्रतिस्पर्धात्मक अंतर है?
अगर हाँ, अगर यह वह चीज़ है जो तुम्हारे उत्पाद को असल में अलग बनाती है, तो बनाना गंभीर विचार के लायक है। अगर नहीं, तो यहाँ रुको। खरीदो।
सवाल 2: क्या कोई पर्याप्त SaaS विकल्प मौजूद है?
पर्याप्त, पूर्ण नहीं। संस्थापक नियमित रूप से निर्माण करते हैं क्योंकि "बाहर कोई भी वास्तव में वह नहीं करता जो हमें चाहिए।" कभी-कभी यह सच होता है। अक्सर इसका मतलब है कि उन्होंने काफी गहराई से नहीं देखा है, या वे "हमें इसे अच्छी तरह कॉन्फ़िगर करने की आवश्यकता है" को "हमें कुछ नया बनाने की आवश्यकता है" से भ्रमित कर रहे हैं।
मैं किसी भी कस्टम बिल्ड की सिफारिश करने से पहले SaaS बाज़ार पर कम से कम दो घंटे शोध करता हूँ। Product Hunt और G2 यहाँ सच में उपयोगी हैं, सुसमाचार के रूप में नहीं बल्कि एक शुरुआती सूची के रूप में।
सवाल 3: आपका वास्तविक समय-से-मूल्य क्या है?
एक SaaS टूल आज ही लाइव हो सकता है। कस्टम बिल्ड में कम से कम हफ्तों लगते हैं, आमतौर पर महीने। अगर स्पीड मायने रखती है, और अर्ली-स्टेज कंपनियों में लगभग हमेशा रखती है, तो SaaS खरीदना आपको यह सीखने का समय देता है कि आपको वास्तव में क्या चाहिए, इससे पहले कि आप बिल्ड करने के लिए प्रतिबद्ध हों।
2022 में, Seahawk ने एक लॉजिस्टिक्स स्टार्टअप के साथ काम किया जो एक कस्टम रूट-ऑप्टिमाइजेशन डैशबोर्ड चाहता था। हमने उन्हें पहले एक व्हाइट-लेबल्ड API लेयर का इस्तेमाल करने के लिए राजी किया (उन्होंने Route4Me को शुरुआती बिंदु के रूप में इस्तेमाल किया)। छह महीने बाद, उन्हें पता चल गया कि उनके ग्राहक वास्तव में कौन सी तीन सुविधाओं की परवाह करते हैं। जिस कस्टम बिल्ड को उन्होंने अंत में कमीशन किया, वह आधे स्कोप का था, और दोगुना बेहतर था, क्योंकि उन्होंने प्रोडक्शन में सीखा था, न कि किसी स्पेक डॉक्यूमेंट में।
सवाल 4: जब यह टूट जाता है तो क्या होता है?
क्योंकि यह break होगा। सवाल यह है कि कौन इसे ठीक करता है और कितनी तेज़ी से। SaaS के साथ, आप एक support ticket file करते हैं और Twitter पर शिकायत करते हैं। custom software के साथ, आप अपनी dev team को call करते हैं। अगर आपके पास एक dev team retained नहीं है, तो आप trouble में हैं। यह hypothetical नहीं है, मैंने founders को broken custom software के साथ stuck देखा है हफ्तों के लिए क्योंकि उनका freelance developer छुट्टी पर गया।
---
जब बिल्डिंग स्पष्ट रूप से सही विकल्प है
ऐसी परिस्थितियाँ हैं जहाँ कस्टम स्पष्ट रूप से सही है। मुझे उन्हें साफ़ साफ़ बताने दीजिए।
- आपका मूल IP सॉफ़्टवेयर ही है। यदि आप एक SaaS प्रोडक्ट बेच रहे हैं, तो आप जो बेच रहे हैं उसे आउटसोर्स नहीं कर सकते।
- नियामक आवश्यकताएँ मतलब कि शेल्फ से ऐसा-वैसा काम नहीं करेगा। कुछ fintech, healthcare, और कानूनी अनुप्रयोगों में अनुपालन की कमी है जो अधिकांश SaaS टूल को संतुष्ट करने के लिए निर्मित नहीं हैं।
- आप पहले से ही एक SaaS टूल के साथ सत्यापित कर चुके हैं और आप बिल्कुल जानते हैं कि आपको क्या चाहिए। कस्टम बिल्ड कमीशन करने से पहले यह सबसे अच्छी संभव स्थिति है।
- स्केल पर SaaS मूल्य निर्धारण वास्तव में स्वामित्व से अधिक महंगा है। अपने प्रक्षेपित वर्ष 3 उपयोग पर गणित करें। कभी-कभी कस्टम शुद्ध अर्थशास्त्र पर जीतता है।
---
जब खरीदना साफ़ तौर पर सही कॉल है
इसी तरह, कुछ परिस्थितियां खरीदना ज़ाहिर कर देती हैं:
- आप प्री-रेवेन्यू या प्री-प्रोडक्ट-मार्केट फिट हैं। बस इतना ही।
- यह फंक्शन कमोडिटी इन्फ्रास्ट्रक्चर है – ईमेल, पेमेंट्स, ऑथ, स्टोरेज, एनालिटिक्स।
- आपको इसे इस क्वार्टर में काम करना चाहिए, इस साल में नहीं।
- आपकी टीम के पास कोई इन-हाउस इंजीनियरिंग क्षमता नहीं है और आप सही तरीके से किराए पर नहीं ले सकते।
मैं यह भी कहूँगा: अगर आप कोई कठिन बिज़नेस डिसीजन लेने से बचने के लिए फाउंडर के रूप में बना रहे हो, तो यह सोचने लायक है। कस्टम बिल्ड्स बहुत महँगा प्रोक्रास्टिनेशन हो सकते हैं।
---
हाइब्रिड अप्रोच (अक्सर सबसे स्मार्ट कदम)
यहाँ वह चीज़ है जिसे लोग पर्याप्त रूप से चर्चा नहीं करते: बिल्ड और बाय परस्पर विरोधी नहीं हैं।
सबसे प्रैक्टिकल अप्रोच जो मैंने बार-बार काम करते देखा है, वह यह है: कमोडिटी पीसेस को आक्रामक तरीके से खरीदो, और ऊपर से डिफरेंशिएटेड लॉजिक की एक पतली लेयर बिल्ड करो। आपका CRM HubSpot है। आपका सपोर्ट डेस्क Intercom है। लेकिन वह बेस्पोक वर्कफ्लो इंजन जो उन्हें कनेक्ट करता है और आपकी स्पेसिफिक प्रोसेस को ऑटोमेट करता है? वह दो हफ्तों का कस्टम dev है, छह महीने का नहीं।
Seahawk में, हमने WordPress पर सैकड़ों साइटें बनाईं, एक खरीदा गया प्लेटफॉर्म, कस्टम प्लगइन्स के साथ जिन्होंने वास्तव में उपन्यास चीजें कीं। प्लेटफॉर्म ने 80% संभाला। हमने वह 20% बनाया जो मायने रखता था। यह उबाऊ सलाह है। यह भी वह सलाह है जो सबसे अधिक बार काम करी है।
---
FAQ
मुझे कैसे पता चले कि मेरा यूज़ केस वाकई यूनिक है कस्टम बिल्ड को सही ठहराने के लिए?
ईमानदार जवाब: ज्यादातर नहीं हैं। शुरुआत करो एक सीरियस दोपहर बिताकर – मेरा मतलब चार या पांच घंटे, बीस मिनट नहीं – अपनी कैटेगरी में हर SaaS प्रोडक्ट को मैप करके। अगर तुमने यह कर लिया है और कुछ भी तुम्हारी कोर requirement को कवर नहीं करता, तो अपने आप से पूछो कि क्या वह requirement अभी वास्तव में जरूरी है या यह एक नाइस-टू-हेव है जिसे तुमने एक ब्लॉकर में एलीवेट कर दिया है। अगर यह सच में जरूरी है और सच में अनसर्व्ड है, तो यह एक सिग्नल है जिसे सीरियसली लेने लायक है।
कस्टम सॉफ्टवेयर को जिम्मेदारी से अपने पास रखने के लिए आपको न्यूनतम कौन सी टीम चाहिए?
कम से कम: एक डेवलपर जो कोडबेस को गहराई से समझता है, और या तो एक दूसरा डेवलपर या एक retained एजेंसी जो कवर कर सके जब वह अनुपलब्ध हो। कस्टम सॉफ्टवेयर की ओनिंग एक सिंगल फ्रीलांसर और कोई बैकअप के साथ एक नाजुक पोजीशन है। मैंने इसे असली ऑपरेशनल डैमेज का कारण बनते देखा है जब वह एक व्यक्ति अनुपलब्ध हो जाता है – छुट्टी, बीमारी, एक बेहतर जॉब ऑफर।
क्या मुझे in-house बनाना चाहिए या कस्टम बनवाने के लिए किसी एजेंसी को किराए पर लेना चाहिए?
यह लगभग पूरी तरह इस बात पर निर्भर करता है कि सॉफ्टवेयर आपका core business है या नहीं। अगर आप एक सॉफ्टवेयर कंपनी हैं, तो आप शायद eventually in-house चाहते हैं, भले ही शुरुआत के लिए किसी एजेंसी का उपयोग करें। अगर सॉफ्टवेयर एक tool है जो आपके business को support करता है न कि business ही है, तो proper SLA वाला एजेंसी संबंध आमतौर पर full-time engineers को किराए पर लेने से ज्यादा cost-effective होता है।
क्या open-source बनाने और खरीदने के बीच एक बीच का रास्ता है?
हां, और यह अंडरयूज्ड है। Metabase जैसे टूल्स एनालिटिक्स के लिए, Directus हेडलेस CMS के लिए, या ERPNext ऑपरेशन्स के लिए तुम्हें कस्टम सॉफ्टवेयर की फ्लेक्सिबिलिटी देते हैं काफी कम इनिशियल बिल्ड कॉस्ट के साथ। कैच: तुम अभी भी इन्फ्रास्ट्रक्चर की ओनिंग कर रहे हो और तुम्हें अभी भी किसी टेक्निकल को इसे मैनेज करने की जरूरत है। यह फ्री नहीं है, बस शुरुआत के लिए सस्ता है।
---
एक अंतिम विचार
बिल्ड बनाम बाई का सवाल एक जवाब नहीं रखता। इसका आपका जवाब है, आपके स्टेज के लिए, आपकी टीम के लिए, आपकी कॉम्पिटिटिव पोज़िशन के लिए, और आपने अभी तक जो वेलिडेट किया है उसके लिए।
जिस चीज पर मैं पुश बैक करूंगा, वह बिल्डिंग के चारों ओर रोमांटिसिज्म है। कस्टम सॉफ्टवेयर inherently अधिक सीरियस, अधिक स्केलेबल, या अधिक इंप्रेसिव नहीं है एक अच्छी तरह से कॉन्फिगर किए गए SaaS स्टैक की तुलना में। जिस इनवॉयसिंग फाउंडर का मैंने शुरुआत में जिक्र किया था? वह अंत में कुछ genuinely कस्टम बनाया, लेकिन केवल अठारह महीने बाद Invoice Ninja यूज करने के बाद जो उसे सिखाया कि उसके ग्राहकों को वास्तव में क्या चाहिए। बिल्ड इंतजार के लिए बेहतर था।
boring option से शुरू करो। कुछ नया बनाने का अधिकार अर्जित करो।
संबंधित पढ़ना: Next.js और Supabase के साथ एक Real-Time Auction Site बनाना, bespoke web development, और Next.js।