एक क्लाइंट ने मुझे 2021 में फोन किया — उसकी आवाज़ में असली घबराहट थी। उसने चौदह महीनों में एक कस्टम इनवॉइसिंग प्लेटफॉर्म बनाने में £140,000 खर्च किए थे। उसकी dev टीम ने शायद 60% spec डिलीवर किया था। और महीने ग्यारह के आसपास, उसे पता चला कि Invoice Ninja मौजूद था, open-source था, और जो उसे चाहिए उसका 90% बॉक्स से ही कर देता था। मुफ़्त में।Invoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
वह कॉल मुझे थोड़ा सताता है। क्योंकि सच यह है: मैंने भी विपरीत गलती की है। Seahawk के पास 2019 में एक प्रोजेक्ट था जहाँ हमने आठ महीने पाँच अलग-अलग SaaS टूल्स — Airtable, Zapier, Typeform, HubSpot, और एक कस्टम Webflow CMS — को एक साथ जोड़ने में लगाए, क्लाइंट वर्कफ्लो को मैनेज करने के लिए, जो पिछली नज़र में, एक £15,000 की कस्टम बिल्ड ने साफ़-सुथरे और स्थायी तरीक़े से हल कर दिया होता। हम महीने के अंत तक सदस्यता में लगभग £900/महीना चुका रहे थे। इसे तीन साल पर गिनते हो।
न तो कोई भी चरम स्वतः सही है। और कोई भी व्यक्ति जो आपको साफ़ नियम बेच रहा है — "हमेशा बनाओ", "कभी मत बनाओ" — कुछ बेच रहा है। तो यहाँ वह असली ढाँचा है जो मैं इस्तेमाल करता हूँ जब कोई संस्थापक मेरे साथ बैठकर सवाल पूछता है।
---
पहले, स्वीकार करो कि तुम असल में क्या फैसला कर रहे हो
यह कोई तकनीकी निर्णय नहीं है। सच कहूँ तो नहीं। यह एक व्यावसायिक निर्णय है जो तकनीकी कपड़ों में तैयार किया गया है।
जब आप कहते हैं "क्या मुझे बनाना चाहिए या खरीदना चाहिए?", तो आप असल में पूछ रहे होते हैं: मेरे प्रोडक्ट में अंतर कहाँ है? अगर जो चीज़ आप बनाने का विचार कर रहे हैं वह आपके प्रतिस्पर्धी लाभ के मूल में है — वह कारण जिससे ग्राहक आपको उनके ब्राउज़र के अगले टैब पर जाने की जगह चुनेंगे — तो बनाना शायद सही है। अगर यह बुनियादी ढाँचा, प्रशासनिक, या सामान्य कार्यक्षमता है, तो खरीदना लगभग निश्चित रूप से वास्तविक शब्दों में सस्ता है।reasoncustomers 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 Reporthas 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.
- फ्रैंकेन-स्टैक जटिलता। पाँच टूल जो 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, स्पष्ट रूप से। प्रमाणीकरण? Auth0 या Clerk। कोई भी 2024 में अपना खुद का भुगतान प्रोसेसर नहीं बनाना चाहिए।Postmarkor 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 Huntand G2 are genuinely useful here — not as gospel but as a starting inventory.
सवाल 3: आपका वास्तविक समय-से-मूल्य क्या है?
एक SaaS टूल आज ही लाइव हो सकता है। कस्टम बिल्ड कम से कम हफ्तों का समय लेता है, आमतौर पर महीने। अगर स्पीड मायने रखता है — और शुरुआती दौर की कंपनियों में लगभग हमेशा ही रखता है — खरीदना आपको यह सीखने का समय देता है कि आपको वास्तव में क्या चाहिए, इससे पहले कि आप इसे बनाने का फैसला करें।
2022 में, Seahawk ने एक लॉजिस्टिक्स स्टार्टअप के साथ काम किया जो एक कस्टम रूट-ऑप्टिमाइजेशन डैशबोर्ड चाहता था। हमने उन्हें पहले एक white-labelled API लेयर का इस्तेमाल करने के लिए राज़ी किया (उन्होंने शुरुआती बिंदु के रूप में Route4Me का इस्तेमाल किया)। छह महीने बाद, उन्हें बिल्कुल पता था कि उनके कस्टमर्स को किन तीन फीचर्स की परवाह है। कस्टम बिल्ड जो उन्होंने आखिरकार कमीशन किया, वह आधे स्कोप का था — और दोगुना बेहतर — क्योंकि उन्होंने एक स्पेक डॉक्यूमेंट के बजाय प्रोडक्शन में सीखा था।Route4Meas 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 टीम को कॉल करते हैं। अगर आपके पास कोई dev टीम retain नहीं है, तो आप मुश्किल में हैं। यह कोई काल्पनिक बात नहीं है — मैंने फाउंडर्स को देखा है जो टूटे हुए कस्टम सॉफ़्टवेयर के साथ हफ्तों तक फंसे रहे क्योंकि उनका फ्रीलांस डेवलपर छुट्टी पर चला गया।
---
जब बिल्डिंग स्पष्ट रूप से सही विकल्प है
ऐसी परिस्थितियाँ हैं जहाँ कस्टम स्पष्ट रूप से सही है। मुझे उन्हें साफ़ साफ़ बताने दीजिए।
- आपका कोर IP स्वयं सॉफ़्टवेयर है। अगर आप एक SaaS प्रोडक्ट बेच रहे हैं, तो आप उस चीज़ को आउटसोर्स नहीं कर सकते जो आप बेच रहे हैं।If you're selling a SaaS product, you can't outsource the thing you're selling.
- नियामक आवश्यकताएँ मतलब off-the-shelf काम नहीं करेगा। कुछ fintech, healthcare, और legal अनुप्रयोगों में compliance बाधाएँ हैं जो अधिकांश 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 की कीमत सच में ओनरशिप से ज्यादा महंगी होती है। अपने प्रोजेक्टेड Year 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 है। लेकिन वह कस्टम वर्कफ़्लो इंजन जो उन्हें जोड़ता है और आपकी विशिष्ट प्रक्रिया को ऑटोमेट करता है? वह छह महीने नहीं, दो हफ्तों का कस्टम डेवलपमेंट है।
Seahawk में, हमने WordPress — एक खरीदे गए प्लेटफॉर्म — पर सैकड़ों साइटें बनाई हैं जिसमें कस्टम प्लगइन हैं जो वास्तव में नई चीज़ें करते हैं। प्लेटफॉर्म 80% को संभालता है। हम वह 20% बनाते हैं जो मायने रखता है। यह बोरिंग सलाह है। यह भी वह सलाह है जो सबसे अधिक काम करती है।
---
FAQ
मुझे कैसे पता चले कि मेरा यूज़ केस वाकई यूनिक है कस्टम बिल्ड को सही ठहराने के लिए?
ईमानदार उत्तर: ज्यादातर नहीं हैं। एक गंभीर दोपहर बिताकर शुरू करें — मेरा मतलब चार या पाँच घंटे, बीस मिनट नहीं — अपनी कैटेगरी में हर SaaS प्रोडक्ट को मैप करें। यदि आपने ऐसा किया है और कुछ भी आपकी कोर आवश्यकता को कवर नहीं करता, तो अपने आप से पूछें कि क्या वह आवश्यकता वास्तव में अभी आवश्यक है या क्या यह एक नाइस-टू-हैव है जिसे आपने एक ब्लॉकर में बदल दिया है। यदि यह वास्तव में आवश्यक है और वास्तव में अनसर्विस्ड है, तो यह एक सिग्नल है जिसे गंभीरता से लेने लायक है।necessary right nowor 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.
कस्टम सॉफ्टवेयर को जिम्मेदारी से अपने पास रखने के लिए आपको न्यूनतम कौन सी टीम चाहिए?
न्यूनतम: एक डेवलपर जो कोडबेस को गहराई से समझता हो, और दूसरा डेवलपर या कोई retained एजेंसी जो उनकी अनुपलब्धता के समय कवर कर सके। एक ही फ्रीलांसर के साथ कस्टम सॉफ्टवेयर का मालिक होना और कोई बैकअप न होना एक नाजुक स्थिति है। मैंने देखा है कि यह असली operational नुकसान का कारण बन सकता है जब वह एक व्यक्ति उपलब्ध नहीं रहता — छुट्टी, बीमारी, बेहतर नौकरी का ऑफर।
क्या मुझे in-house बनाना चाहिए या कस्टम बनवाने के लिए किसी एजेंसी को किराए पर लेना चाहिए?
यह लगभग पूरी तरह इस बात पर निर्भर करता है कि सॉफ्टवेयर आपका core business है या नहीं। अगर आप एक सॉफ्टवेयर कंपनी हैं, तो आप शायद eventually in-house चाहते हैं, भले ही शुरुआत के लिए किसी एजेंसी का उपयोग करें। अगर सॉफ्टवेयर एक tool है जो आपके business को support करता है न कि business ही है, तो proper SLA वाला एजेंसी संबंध आमतौर पर full-time engineers को किराए पर लेने से ज्यादा cost-effective होता है।
क्या open-source बनाने और खरीदने के बीच एक बीच का रास्ता है?
हां, और इसका उपयोग कम होता है। Metabase जैसे analytics tools, Directus headless CMS के लिए, या ERPNext operations के लिए आपको कस्टम सॉफ्टवेयर की flexibility देते हैं significantly कम प्रारंभिक build cost के साथ। पकड़: आप अभी भी infrastructure के मालिक हैं और आपको अभी भी इसे manage करने के लिए किसी technical व्यक्ति की जरूरत है। यह मुफ्त नहीं है — यह बस शुरुआत करने के लिए सस्ता है।Metabasefor 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.
---
एक अंतिम विचार
build vs buy सवाल का एक ही जवाब नहीं है। इसका आपका जवाब है, आपके stage के लिए specific, आपकी team के लिए, आपकी competitive position के लिए, और आपने अब तक क्या validate किया है।youranswer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
जो मैं challenge करूंगा वह है building के चारों ओर की romanticism। कस्टम सॉफ्टवेयर inherently ज्यादा गंभीर, ज्यादा scalable, या अच्छी तरह से configure किए गए SaaS stack से ज्यादा impressive नहीं है। शुरुआत में मैंने जिस invoicing founder का जिक्र किया था? उसने eventually कुछ genuinely custom बनाया — लेकिन केवल अठारह महीने बाद Invoice Ninja का उपयोग करने के बाद जिससे उसे यह समझ आ गई कि उसके customers को वास्तव में क्या चाहिए। यह wait के लिए बेहतर था।
boring option से शुरू करो। कुछ नया बनाने का अधिकार अर्जित करो।