हाल ही में "SaaS is dead" वाक्यांश काफी ट्रेंड कर रहा है। तर्क यह है कि जब हम ऐसे युग में हैं जहां AI कोड लिख सकता है, तो हमें SaaS के लिए हर महीने फीस देना बंद कर देना चाहिए और जो भी चाहिए उसे इन-हाउस बना लेना चाहिए।
मेरी कंपनी Emooove में, हम पिछले कुछ महीनों से अपने आंतरिक सिस्टम को इन-हाउस बनाने में पूरी तरह से जुटे हुए हैं। इसे वास्तव में करने के बाद, मैंने सफलताओं और दर्दनाक सबक दोनों का अनुभव किया है। आज, मैं उस वास्तविक अनुभव के आधार पर "SaaS is dead" वाले नैरेटिव पर अपना दृष्टिकोण साझा करना चाहता हूं।
स्पष्ट होने के लिए, मैं यह एक सिस्टम के उपयोगकर्ता/निर्माता के दृष्टिकोण से लिख रहा हूं, न कि SaaS प्रदाता के रूप में।
एक अद्भुत युग जहां कोई भी सिस्टम बना सकता है
सबसे पहले, एक आधार के रूप में, Claude Code के आगमन ने वास्तव में एक ऐसा युग ला दिया है जहां "कोई भी सिस्टम बना सकता है।" यह कोई अतिशयोक्ति नहीं है।
Emooove में, एक रिक्रूटमेंट लीड जो हमारे साथ केवल दो महीने से थी, उसने एक इन-हाउस ATS (Applicant Tracking System) बनाया। वह एक गैर-इंजीनियर है और उसे इंजीनियरिंग का कोई अनुभव नहीं है। इसके बावजूद, उसने एक कार्यशील सिस्टम बना दिया जो आवेदकों को आयात करने से लेकर चयन प्रबंधन और डैशबोर्ड तक सब कुछ संभालता है।
इसके अलावा, हम वर्तमान में अपने मुख्य व्यवसाय, सेल्स एजेंसी सेवाओं की परिचालन दक्षता और गुणवत्ता में सुधार के लिए एक आंतरिक सिस्टम विकसित कर रहे हैं। मैं खुद रोज़ इस पर काम कर रहा हूं, और शुरू करने के दो सप्ताह से भी कम समय में, मुझे लगता है कि हम कुछ काफी अच्छा बनाने के कगार पर हैं।
जब आप कुछ ऐसा इन-हाउस बना सकते हैं जिसके लिए अन्यथा प्रति माह दसियों या सैकड़ों हज़ारों येन की SaaS फीस चुकानी पड़ती, तो यह समझना आसान है कि लोग "SaaS is dead" क्यों कहना चाहते हैं।
हालांकि, यह सब इतना आसान नहीं है
यही मुख्य बिंदु है। जब हमने वास्तव में इसे करके देखा, तो यह सब गुलाबी नहीं था।
1. रखरखाव बेहद कठिन है
अच्छे या बुरे के लिए, आप चीजों को "चलते-फिरते" बना सकते हैं, इसलिए वे जल्दी आकार ले लेती हैं। हालांकि, क्योंकि आवश्यकताएं पूरी तरह से स्पष्ट नहीं होती हैं, कई कमियां बनी रहती हैं।
हमारे ATS के मामले में, हमने ऐसी चीजें देखीं:
- जो एंट्री आयात होनी चाहिए थीं, वे नहीं हुईं।
- डैशबोर्ड के आंकड़े किसी तरह गड़बड़ थे।
- महत्वपूर्ण बटन गायब थे, जिससे ऑपरेशन ठप हो गए।
हमें कई ऐसी कमियां मिलीं जो उपयोग शुरू करने के बाद ही नज़र आईं। हमारे आंतरिक सेल्स सपोर्ट सिस्टम के साथ, एक सुबह तो अचानक हम उसे एक्सेस ही नहीं कर सके और स्क्रीन नहीं खुली।
बेशक, आवश्यकताओं को अधिक सावधानी से परिभाषित करके या चलते-चलते सुधार करके इन्हें कुछ हद तक ठीक किया जा सकता है। हालांकि, उस दौरान, सामान्य व्यावसायिक संचालन बाधित होता है। अगर आप इस उम्मीद के साथ बनाना शुरू करते हैं कि यह "आसान और तेज़" होगा, तो आप मुश्किल में पड़ जाएंगे। मैंने महसूस किया कि आपको "बनाओ और खत्म करो" की मानसिकता से नहीं, बल्कि "बनाओ और सुधारते रहो" की मानसिकता से शुरुआत करनी चाहिए।
चूंकि हमारा रिक्रूटमेंट स्केल छोटा है, हम ATS के कुछ देर के लिए बंद होने पर भी काम चला सकते हैं। लेकिन अगर यह कई हितधारकों वाला सिस्टम होता, तो सोचकर ही कंपकंपी हो जाती है। जैसे-जैसे उपयोगकर्ताओं की संख्या और प्रभाव का दायरा बढ़ते हैं, एक भी विफलता से होने वाला नुकसान बढ़ता है, और कठिनाई का स्तर आसमान छू लेता है।
हालांकि आप आंतरिक सिस्टम के लिए इसे बर्दाश्त कर सकते हैं, लेकिन बाहरी बिक्री के लिए या बाहरी दुनिया से जुड़ी किसी भी चीज़, जैसे इंक्वायरी फॉर्म, को बनाने में आपको बेहद सतर्क रहना चाहिए।
2. UI/UX कभी पॉलिश नहीं हो पाता
सिस्टम खुद बनाते समय मुझे यह एहसास हुआ: फिनिश कुछ हद तक औसत दर्जे की होती है।
AI पहली बार जो स्क्रीन बनाता है, वे "ठीक-ठाक" लगती हैं, लेकिन जब आप वास्तव में उन्हें इस्तेमाल करते हैं, तो विवरण बेढंगे होते हैं। हालांकि बार-बार निर्देश देकर आप अंततः इसे अच्छा दिखा सकते हैं, लेकिन इसके लिए गहन जुनून और समय चाहिए। अधिकांश लोग संभवतः बीच में ही समझौता कर लेंगे।
SaaS इंटरफेस इसलिए पॉलिश होते हैं क्योंकि पेशेवर डिजाइनरों ने वर्षों तक उपयोगकर्ताओं की प्रतिक्रिया को शामिल किया है; यह ऐसी चीज़ नहीं है जो आपको मुफ्त में मिले।
3. सुरक्षा का मुद्दा
यह सबसे डरावना हिस्सा है।
यहां तक कि गैर-इंजीनियर भी "बस जुगाड़ करो" वाले रवैये से Claude Code का उपयोग करके फंक्शन और UI/UX बना सकते हैं। लेकिन क्या उसी तरह सुरक्षा में भी महारत हासिल करना संभव है? कम से कम मेरे लिए तो नहीं है। प्रमाणीकरण, अनुमति प्रबंधन, कमजोरियों का समाधान—"काम करना" और "सुरक्षित होना" दो बिल्कुल अलग चीजें हैं।
हमारे मामले में, सौभाग्य से हमारे पास सुरक्षा इंजीनियर के रूप में अनुभव वाला एक व्यक्ति है, इसलिए हम यह सुनिश्चित करते हैं कि यह हिस्सा वही संभाले। फिर भी, थोड़ी चिंता बनी रहती है। बिना विशेषज्ञों वाला संगठन ग्राहकों की जानकारी को बिना सोचे-समझे बनाए गए सिस्टम पर डालकर उसे सार्वजनिक कर दे, यह सोचकर ही मुझे ठंडा पसीना आ जाता है।
"जियो या मरो" वाली बाइनरी सोच गलत है
मैंने इन-हाउस डेवलपमेंट के नकारात्मक पहलुओं को सूचीबद्ध किया है, लेकिन सच कहूं तो, इसमें कई अच्छी चीजें भी हैं।
- आप ऐसा सिस्टम बना सकते हैं जो आपके व्यवसाय में पूरी तरह से फिट बैठता है।
- अगर आपको कुछ ठीक करना है, तो आप अगले ही दिन कर सकते हैं।
- लगभग कोई मासिक लागत नहीं होती।
- कंपनी को यह कौशल और आत्मविश्वास मिलता है कि "हम खुद सिस्टम बना सकते हैं।"
समस्या इसे "क्या SaaS जिएगा या मरेगा?" जैसे सरल सवाल में बदलने की है। SaaS अपनाना है या इन-हाउस बनाना है, यह कंपनी की स्थिति पर निर्भर करता है। मेरे अनुभव के आधार पर, विचार करने योग्य पांच बिंदु ये हैं:
बिंदु 1: क्या आपके पास इन-हाउस इंजीनियर हैं?
यदि नहीं, तो आप सुरक्षा जैसे क्षेत्रों में असफल होंगे, जिन्हें गैर-इंजीनियर ऐसे ही संभाल नहीं सकते। सबसे डरावना हिस्सा यह है कि खतरों को समझे बिना फंक्शन बनाना संभव है। निर्णायक बिंदु यह है कि क्या आप प्रमुख क्षेत्रों की समीक्षा के लिए एक अनुभवी व्यक्ति को सुरक्षित कर सकते हैं।
बिंदु 2: हितधारकों की संख्या
यदि बहुत अधिक हैं, तो विफलता होने पर नुकसान बहुत बड़ा होता है, और कठिनाई का स्तर तेजी से बढ़ता है। इसके विपरीत, छोटे संगठन अधिक आसानी से प्रयोग कर सकते हैं क्योंकि चीजें बंद होने पर वे सिर्फ माफी मांग सकते हैं। छोटे प्रभाव वाले कार्यों से शुरुआत करना व्यावहारिक है।
बिंदु 3: बाहरी बनाम आंतरिक सिस्टम
आंतरिक सिस्टम के साथ, कुछ भी होने पर जोखिम सीमित रहता है। हालांकि, किसी भी बाहरी चीज़ के लिए, एक भी सूचना लीक अपरिवर्तनीय हो सकती है। जहां SaaS आपको कुछ जिम्मेदारी विक्रेता को सौंपने की सुविधा देता है, वहीं इन-हाउस डेवलपमेंट में सब कुछ आपकी जिम्मेदारी होती है। बाहरी दुनिया से जुड़ी किसी भी चीज़ के लिए SaaS की "सिद्ध मन की शांति" का मूल्य बढ़ जाता है।
बिंदु 4: क्या आप रखरखाव के लिए मैन-आवर्स आवंटित कर सकते हैं?
रखरखाव का काम आपके विचार से कहीं अधिक होता है। इन-हाउस डेवलपमेंट "बनाओ और खत्म करो" नहीं है, बल्कि "सुधारते रहो" है। क्या आप उसी दूरदृष्टि के साथ शुरुआत कर सकते हैं? अगर आप आधे-अधूरे मन से शुरुआत करेंगे, तो आप कमियों को सुधारने में दब जाएंगे और इसका दबाव आपके मुख्य व्यवसाय पर पड़ेगा।
बिंदु 5: क्या आपको AI डेवलपमेंट पसंद है/आप इसे करना चाहते हैं?
आखिर में, सब कुछ इसी पर आकर टिकता है। यह आपके विचार से अधिक थकाऊ और कठिन है, और जब AI आपकी बात नहीं मानता तो बहुत निराशा होती है (हंसी)। क्या आप फिर भी इसे पूरा कर पाएंगे? यह उन लोगों के लिए एक शानदार युग है
