एक क्लाइंट ने 2021 में मुझे फोन किया -- उसकी आवाज़ में ठीक घबराहट थी। उसने एक कस्टम इनवॉइसिंग प्लेटफॉर्म बनाने में 14 महीनों में £140,000 खर्च किए थे। उसकी डेव टीम ने स्पेक का शायद 60% ही डिलीवर किया था। और महीने ग्यारह के आसपास, उसे पता चला था कि Invoice Ninja मौजूद था, ओपन-सोर्स था, और उसे जो चाहिए था उसका 90% सीधे बॉक्स से बाहर कर देता था। बिल्कुल मुफ़्त।Invoice Ninja existed, was open-source, and did 90% of what he needed out of the box. For free.
मुख्य सीख: SaaS खरीदते रहें जब तक सबस्क्रिप्शन टैक्स, डेटा ओनरशिप या वर्कफ़्लो मेल न खाना वाकई समस्या न बन जाए; कस्टम बनाएँ जब वह टूल आपके बिज़नेस की जीत का मूल हो।Buy SaaS until the subscription tax, data ownership, or workflow mismatch genuinely bites; build custom when the tool is core to how the business wins.
वह कॉल मुझे थोड़ा परेशान करता है। क्योंकि सच्चा जवाब यह है: मैंने विपरीत गलती भी की है। Seahawk के पास 2019 में एक प्रोजेक्ट था जहाँ हमने आठ महीने पाँच अलग-अलग SaaS टूल्स -- Airtable, Zapier, Typeform, HubSpot, और एक कस्टम Webflow CMS -- को एक क्लाइंट वर्कफ़्लो को मैनेज करने के लिए जोड़ने में लगाए, जो बाद में सोचने पर, एक £15,000 कस्टम बिल्ड ने साफ़ और स्थायी रूप से हल कर दिया होता। हम तीन साल से अधिक कुल सदस्यताओं में लगभग £900/माह का भुगतान कर रहे थे। तीन साल में गणित करो।
कोई भी चरम स्वचालित रूप से सही नहीं है। और कोई भी व्यक्ति जो आपको एक साफ़ नियम बेच रहा है -- "हमेशा बनाओ", "कभी न बनाओ" -- कुछ बेच रहा है। तो यहाँ वह वास्तविक ढाँचा है जो मैं इस्तेमाल करता हूँ जब एक फाउंडर मेरे साथ बैठता है और सवाल पूछता है।
---
पहले, स्वीकार करो कि तुम असल में क्या फैसला कर रहे हो
यह कोई तकनीकी निर्णय नहीं है। सच कहूँ तो नहीं। यह एक व्यावसायिक निर्णय है जो तकनीकी कपड़ों में तैयार किया गया है।
जब आप कहते हैं "क्या मुझे बनाना चाहिए या खरीदना चाहिए?", तो आप वास्तव में पूछ रहे हैं: मेरे प्रोडक्ट में अंतर कहाँ रहता है? अगर जो चीज़ आप बनाने पर विचार कर रहे हैं वह आपके प्रतिस्पर्धात्मक लाभ के लिए मूल है -- कारण कि ग्राहक आपको अपने ब्राउज़र में अगली टैब के बजाय चुनेंगे -- तो बनाना शायद समझदारी है। अगर यह इंफ्रास्ट्रक्चर, एडमिन, या कमोडिटी कार्यक्षमता है, तो खरीदना लगभग निश्चित रूप से वास्तविक शर्तों में सस्ता है।reason customers will choose you over the next tab in their browser -- then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
मैं संस्थापकों से पहले एक सवाल पूछता हूँ: क्या आपके यूज़र्स इस चीज़ को कभी देखेंगे? अगर जवाब हाँ है और यह किसी सार्थक तरीके से उनके अनुभव को आकार देता है, तो इसे बनाना शायद लायक है। अगर यह बैक-ऑफिस, ऑपरेशनल, या आंतरिक है, तो बनाने के लिए बार बहुत ऊँचा होना चाहिए।Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
निर्माण की वास्तविक लागत (लोग इसका बुरी तरह अनुमान लगाते हैं)
मैं सीधे कहता हूँ। कस्टम विकास आपके सोचने से ज़्यादा खर्च करता है, जो आपको बताया जाता है उससे अधिक समय लेता है, और चल रहे रखरखाव की आवश्यकता होती है जिसका किसी ने बजट नहीं बनाया।
संस्थापक असल में क्या कीमत में डालना भूलते हैं
- रखरखाव और होस्टिंग। एक बार की बात नहीं। आप हुक पर हमेशा के लिए हैं जब तक आप चीज़ को सूर्यास्त नहीं करते।Not a one-off. You're on the hook forever unless you sunset the thing.
- सुरक्षा पैच। एक SaaS विक्रेता यह आपके लिए संभालता है। आप इसे बनाते हैं, आप इसके मालिक हैं, 2 बजे के अलर्ट सहित।A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- नए डेवेलपर्स को ऑनबोर्ड करना। अगर आपका लीड इंजीनियर चला जाता है, तो अगले व्यक्ति को आपके कोडबेस को सीखना होता है। वह बिलेबल समय के हफ्तों हैं।If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- फीचर क्रीप। स्टेकहोल्डर्स एक कस्टम टूल देखते हैं और मानते हैं कि यह सबकुछ कर सकता है। स्कोप बढ़ता है। लागतें इसके पीछे चलती हैं।Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
एक रफ रूल जो मैं इस्तेमाल करता हूँ: अपने शुरुआती डेव एस्टीमेट को लें, यथार्थवादी डिलीवरी के लिए 1.6 से गुणा करें, फिर उस नंबर का 20% सालाना मेंटेनेंस के लिए जोड़ें। अगर ये नंबर अभी भी बिजनेस केस को सपोर्ट करते हैं, तो बढ़िया। अगर नहीं, तो आपके पास आपका जवाब है।
ईमानदारी से कहूँ, तो Standish Group की CHAOS Report दशकों से दिखा रही है कि सॉफ़्टवेयर प्रोजेक्ट्स अपने बजट को चौंकाने वाली दर पर ओवररन करते हैं। संख्या 45-50% प्रोजेक्ट्स के "चुनौतीपूर्ण" या बिल्कुल विफल होने के आसपास बैठती है। यह कभी न बनाने का कारण नहीं है -- यह साफ़ आँखों से जाने का कारण है।Standish Group's CHAOS Report has been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build -- it's a reason to go in clear-eyed.
---
SaaS की असली लागत (यह भी कम आंकी गई है, बस अलग तरीके से)
SaaS सस्ता दिखता है जब तक वह नहीं रहता।
£49/माह की योजना जो साल की शुरुआत में उचित लग रही थी, तीन साल बाद £490/माह बनने की मज़ेदार आदत है -- एक बार जब आप एक उच्च टायर पर हों, आपने सीटें जोड़ दी हैं, और विक्रेता ने "प्राइसिंग रीस्ट्रक्चर" (पढ़ें: बढ़ोतरी) कर दिया है। मैंने यह Salesforce, Intercom, और Mixpanel पर क्लाइंट्स के साथ देखा है। यह दुर्भावनापूर्ण नहीं है। यह सिर्फ़ यही है कि SaaS अर्थशास्त्र कैसे काम करता है।
फाउंडर्स तीन SaaS जालों में फंसते हैं
- विक्रेता पर निर्भरता। आपका डेटा उनके फॉर्मेट में है, उनके स्कीमा में, उनके एक्सपोर्ट फ्लो में। चले जाना मुश्किल है और कभी-कभी महत्वपूर्ण डेटा इंजीनियरिंग काम के बिना प्रभावी रूप से असंभव है।Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- Franken-stack जटिलता। पाँच टूल जो Zapier के माध्यम से कुछ-कुछ एकीकृत होते हैं, एक सिस्टम नहीं है। यह एक दायित्व है। एक API का अवमूल्यन और चीजें टूटने लगती हैं।Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- सदस्यता में रिसाव। कोई भी अपने टूल स्टैक की सालाना जांच नहीं करता। उन्हें करना चाहिए। मैंने पिछले साल एक 12-व्यक्ति एजेंसी के लिए एक ऑडिट चलाया और £3,200/माह SaaS पाया जिसे वे या तो उपयोग करना बंद कर चुके थे या प्रत्येक के लिए एक फीचर के लिए उपयोग कर रहे थे।Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
कहा कि -- कमोडिटी फ़ंक्शन्स के लिए, SaaS लगभग हमेशा सही कॉल है। ईमेल डिलीवरी? Postmark या SendGrid। पेमेंट्स? Stripe, स्पष्ट रूप से। Auth? Auth0 या Clerk। 2024 में कोई भी अपना खुद का पेमेंट प्रोसेसर नहीं बनाना चाहिए।Postmark or SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
एक फ्रेमवर्क जो वास्तव में काम करता है
ठीक है। मैं इसे कैसे सोचता हूँ, यह बताता हूँ। चार सवाल, क्रम में।
सवाल 1: क्या यह एक प्रतिस्पर्धात्मक अंतर है?
अगर हाँ -- अगर यह वह चीज़ है जो आपके प्रोडक्ट को वास्तव में अलग बनाती है -- बनाना गंभीर विचार के लायक है। अगर नहीं, यहाँ रुको। खरीदो।
सवाल 2: क्या कोई पर्याप्त SaaS विकल्प मौजूद है?
पर्याप्त, पूर्ण नहीं। संस्थापक नियमित रूप से निर्माण करते हैं क्योंकि "बाहर कोई भी वास्तव में वह नहीं करता जो हमें चाहिए।" कभी-कभी यह सच होता है। अक्सर इसका मतलब है कि उन्होंने काफी गहराई से नहीं देखा है, या वे "हमें इसे अच्छी तरह कॉन्फ़िगर करने की आवश्यकता है" को "हमें कुछ नया बनाने की आवश्यकता है" से भ्रमित कर रहे हैं।
मैं SaaS बाज़ार पर गंभीरता से शोध करने में कम से कम दो घंटे लगाता हूँ इससे पहले कि मैं कभी एक कस्टम बिल्ड की सिफारिश करूँ। Product Hunt और G2 यहाँ वास्तव में उपयोगी हैं -- सुसमाचार के रूप में नहीं बल्कि एक शुरुआती इन्वेंटरी के रूप में।Product Hunt and G2 are genuinely useful here -- not as gospel but as a starting inventory.
सवाल 3: आपका वास्तविक समय-से-मूल्य क्या है?
एक SaaS टूल आज लाइव हो सकता है। एक कस्टम बिल्ड कम से कम हफ्तों का काम है, आमतौर पर महीने। अगर स्पीड मायने रखती है — और अर्ली-स्टेज कंपनियों में यह लगभग हमेशा रखती है — खरीदारी आपको सीखने का समय देती है कि आपको वास्तव में क्या चाहिए इससे पहले कि आप बिल्ड करने के लिए प्रतिबद्ध हों।
2022 में वापस, Seahawk एक लॉजिस्टिक्स स्टार्टअप के साथ काम कर रहा था जो एक कस्टम रूट-ऑप्टिमाइज़ेशन डैशबोर्ड चाहता था। हमने उन्हें पहले एक व्हाइट-लेबल्ड API लेयर का उपयोग करने के लिए राजी किया (उन्होंने Route4Me को शुरुआती बिंदु के रूप में इस्तेमाल किया)। छह महीने बाद, वे बिल्कुल जानते थे कि उनके ग्राहकों को वास्तव में कौन सी तीन सुविधाएं चाहती थीं। कस्टम बिल्ड जिसे उन्होंने अंततः कमीशन किया वह आधे स्कोप का था — और दोगुना बेहतर — क्योंकि उन्होंने स्पेक डॉक्यूमेंट के बजाय प्रोडक्शन में सीखा था।Route4Me as a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope -- and twice as good -- because they'd learned in production rather than in a spec document.
सवाल 4: जब यह टूट जाता है तो क्या होता है?
क्योंकि यह टूट जाएगा। सवाल यह है कि इसे कौन ठीक करता है और कितनी तेजी से। SaaS के साथ, आप एक सपोर्ट टिकट फाइल करते हैं और Twitter पर शिकायत करते हैं। कस्टम सॉफ्टवेयर के साथ, आप अपनी dev टीम को कॉल करते हैं। अगर आपके पास कोई retained dev टीम नहीं है, तो आप मुसीबत में हैं। यह काल्पनिक नहीं है — मैंने संस्थापकों को सप्ताह भर टूटे हुए कस्टम सॉफ्टवेयर से फंसा हुआ देखा है क्योंकि उनका freelance developer छुट्टी पर चला गया।
---
जब बिल्डिंग स्पष्ट रूप से सही विकल्प है
ऐसी परिस्थितियाँ हैं जहाँ कस्टम स्पष्ट रूप से सही है। मुझे उन्हें साफ़ साफ़ बताने दीजिए।
- आपका मूल IP सॉफ़्टवेयर ही है। यदि आप एक SaaS प्रोडक्ट बेच रहे हैं, तो आप जो बेच रहे हैं उसे आउटसोर्स नहीं कर सकते।If you're selling a SaaS product, you can't outsource the thing you're selling.
- नियामक आवश्यकताएँ मतलब कि शेल्फ से ऐसा-वैसा काम नहीं करेगा। कुछ fintech, healthcare, और कानूनी अनुप्रयोगों में अनुपालन की कमी है जो अधिकांश SaaS टूल को संतुष्ट करने के लिए निर्मित नहीं हैं।Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- आप पहले से ही एक SaaS टूल के साथ सत्यापित कर चुके हैं और आप बिल्कुल जानते हैं कि आपको क्या चाहिए। कस्टम बिल्ड कमीशन करने से पहले यह सबसे अच्छी संभव स्थिति है।This is the best possible position to be in before commissioning a custom build.
- स्केल पर SaaS मूल्य निर्धारण वास्तव में स्वामित्व से अधिक महंगा है। अपने प्रक्षेपित वर्ष 3 उपयोग पर गणित करें। कभी-कभी कस्टम शुद्ध अर्थशास्त्र पर जीतता है।Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
जब खरीदना साफ़ तौर पर सही कॉल है
इसी तरह, कुछ परिस्थितियां खरीदना ज़ाहिर कर देती हैं:
- आप प्री-रेवेन्यू या प्री-प्रोडक्ट-मार्केट फिट हैं। बस इतना ही।
- यह फंक्शन कमोडिटी इंफ्रास्ट्रक्चर है — ईमेल, पेमेंट्स, ऑथ, स्टोरेज, एनालिटिक्स।
- आपको इसे इस क्वार्टर में काम करना चाहिए, इस साल में नहीं।
- आपकी टीम के पास कोई इन-हाउस इंजीनियरिंग क्षमता नहीं है और आप सही तरीके से किराए पर नहीं ले सकते।
मैं यह भी कहूँगा: अगर आप कोई कठिन बिज़नेस डिसीजन लेने से बचने के लिए फाउंडर के रूप में बना रहे हो, तो यह सोचने लायक है। कस्टम बिल्ड्स बहुत महँगा प्रोक्रास्टिनेशन हो सकते हैं।to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
हाइब्रिड अप्रोच (अक्सर सबसे स्मार्ट कदम)
यहाँ वह चीज़ है जिसे लोग पर्याप्त रूप से चर्चा नहीं करते: बिल्ड और बाय परस्पर विरोधी नहीं हैं।
सबसे व्यावहारिक अप्रोच जो मैंने बार-बार काम करते देखा है वह यह है — कमोडिटी पीस को आक्रामक रूप से खरीदें, और ऊपर डिफरेंशिएटेड लॉजिक की एक पतली लेयर बनाएं। आपका CRM HubSpot है। आपकी सपोर्ट डेस्क Intercom है। लेकिन बेस्पोक वर्कफ़्लो इंजन जो उन्हें कनेक्ट करता है और आपकी स्पेसिफिक प्रोसेस को ऑटोमेट करता है? यह छह महीने नहीं, दो हफ्तों का कस्टम dev है।
Seahawk पर, हमने WordPress — एक खरीदा हुआ प्लेटफॉर्म — पर सैकड़ों साइटें बनाई हैं, कस्टम प्लगइन्स के साथ जो वास्तव में नई चीजें करते हैं। प्लेटफॉर्म 80% को हैंडल करता है। हम 20% बनाते हैं जो मायने रखता है। यह बोरिंग सलाह है। यह भी सलाह है जो सबसे ज्यादा काम आई है।WordPress -- a bought platform -- with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
FAQ
मुझे कैसे पता चले कि मेरा यूज़ केस वाकई यूनिक है कस्टम बिल्ड को सही ठहराने के लिए?
ईमानदार जवाब: ज्यादातर नहीं हैं। एक गंभीर दोपहर बिताना शुरू करें — मेरा मतलब चार या पांच घंटे हैं, बीस मिनट नहीं — अपनी कैटेगरी में हर SaaS प्रोडक्ट को मैप करें। अगर आपने ऐसा किया है और कुछ भी आपकी core requirement को कवर नहीं करता, तो अपने आप से पूछें कि क्या वह requirement वास्तव में अभी आवश्यक है या क्या यह एक nice-to-have है जिसे आपने ब्लॉकर में बदल दिया है। अगर यह सच में आवश्यक है और सच में unserved है, तो यह एक सिग्नल है जो गंभीर ध्यान दिए जाने लायक है।necessary right now or whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
कस्टम सॉफ्टवेयर को जिम्मेदारी से अपने पास रखने के लिए आपको न्यूनतम कौन सी टीम चाहिए?
न्यूनतम: एक developer जो codebase को गहराई से समझता है, और या तो एक दूसरा developer या एक retained agency जो कवर कर सकता है जब वे unavailable हों। कस्टम सॉफ्टवेयर को एक freelancer के साथ और बिना बैकअप के own करना एक नाजुक स्थिति है। मैंने देखा है कि यह वास्तविक ऑपरेशनल नुकसान का कारण बनता है जब वह एक व्यक्ति unavailable हो जाता है — छुट्टी, बीमारी, एक बेहतर नौकरी का offer।
क्या मुझे in-house बनाना चाहिए या कस्टम बनवाने के लिए किसी एजेंसी को किराए पर लेना चाहिए?
यह लगभग पूरी तरह इस बात पर निर्भर करता है कि सॉफ्टवेयर आपका core business है या नहीं। अगर आप एक सॉफ्टवेयर कंपनी हैं, तो आप शायद eventually in-house चाहते हैं, भले ही शुरुआत के लिए किसी एजेंसी का उपयोग करें। अगर सॉफ्टवेयर एक tool है जो आपके business को support करता है न कि business ही है, तो proper SLA वाला एजेंसी संबंध आमतौर पर full-time engineers को किराए पर लेने से ज्यादा cost-effective होता है।
क्या open-source बनाने और खरीदने के बीच एक बीच का रास्ता है?
हां, और यह underused है। Metabase जैसे टूल्स एनालिटिक्स के लिए, Directus headless CMS के लिए, या ERPNext ऑपरेशन्स के लिए आपको कस्टम सॉफ्टवेयर की flexibility देते हैं significantly lower initial build cost के साथ। कैच यह है: आप अभी भी इंफ्रास्ट्रक्चर own कर रहे हैं और आपको अभी भी किसी टेक्निकल को इसे मैनेज करने के लिए चाहिए। यह फ्री नहीं है — यह बस शुरु करने के लिए सस्ता है।Metabase for analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free -- it's just cheaper to start.
---
एक अंतिम विचार
बिल्ड बनाम बाई का सवाल एक जवाब नहीं रखता। इसका आपका जवाब है, आपके स्टेज के लिए, आपकी टीम के लिए, आपकी कॉम्पिटिटिव पोज़िशन के लिए, और आपने अभी तक जो वेलिडेट किया है उसके लिए।your answer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
जो मैं challenge करूंगा वह बिल्डिंग के चारों ओर romanticism है। कस्टम सॉफ्टवेयर inherently अधिक serious, अधिक scalable, या एक well-configured SaaS स्टैक से अधिक impressive नहीं है। शुरुआत में जिस invoicing founder का मैंने जिक्र किया? वह अंततः कुछ genuinely कस्टम बनाया — लेकिन केवल अठारह महीने बाद जब Invoice Ninja का उपयोग करना उन्हें सिखाया कि उनके ग्राहकों को वास्तव में क्या चाहिए। बिल्ड इंतजार के लिए बेहतर था।
boring option से शुरू करो। कुछ नया बनाने का अधिकार अर्जित करो।