- कहा जाता है कि SaaS integration डेवलपर्स को सिर्फ प्रोडक्ट पर फोकस करने देता है, लेकिन हकीकत में हर बार 5 छिपी हुई लागतें (taxes) मौजूद होती हैं
- अपनाने से पहले discovery, sign-up, integration, local development, operations हर चरण में समय, जटिलता और मानसिक बोझ लगातार पैदा होता है
- SaaS की जगह integrated platforms (Cloudflare, Supabase आदि) चुनने पर इस दोहराए जाने वाले खर्च और जटिलता को काफी कम किया जा सकता है
- vendor lock-in एक अपरिहार्य वास्तविकता है, इसलिए कई services मिलाने के बजाय एक integrated platform में development flow बनाए रखना सबसे बेहतर है
- आखिरकार सबसे महत्वपूर्ण चीज़ framework या service नहीं, बल्कि वह software है जिसे मैं बनाना चाहता हूँ
SaaS सिर्फ बेहतर branding वाला vendor lock-in है
- डेवलपर्स अक्सर सुनते हैं, “सिर्फ प्रोडक्ट बनाने पर ध्यान दो”, लेकिन वास्तव में auth, queue, file storage, image optimization जैसे SaaS vendors अपनाने पर कई तरह के बोझ पैदा होते हैं
- सिर्फ पैसों की लागत नहीं, बल्कि समय की खपत, friction, और मानसिक थकान भी होती है.
1. Discovery Tax
- किसी SaaS service को अपनाने से पहले यह समझने की प्रक्रिया जरूरी होती है कि वह वास्तव में कौन-सी functionality और value बेच रही है
- problem-solving का दायरा, मौजूदा stack के साथ compatibility, scale के मुकाबले उचित pricing, documentation की स्पष्टता, और implementation के असामान्य तरीकों जैसे विवरणों का मूल्यांकन करना पड़ता है
- यह research process न तो आसानी से पिछले अनुभव से साझा या दोहराई जा सकती है, और इसका बड़ा हिस्सा subjective decision होता है
- marketing message मेरे लिए फिट बैठेगा या नहीं, और service वास्तव में मददगार होगी या नहीं, इसका फैसला खुद करना पड़ता है
2. Sign-Up Tax
- service चुन लेने के बाद, email और card information देनी पड़ती है
- यह देखना जरूरी है कि usage-based billing संभव है या सिर्फ subscription-based lock-in ही उपलब्ध है
- pricing structure की अपारदर्शिता, जैसे team members को dashboard access देने पर अतिरिक्त लागत लगना, एक समस्या है
- यह भी जांचना पड़ता है कि free trial के बिना testing संभव है या शुरुआत से ही payment मांगी जाती है
- code की एक लाइन लिखने से पहले ही vendor के साथ contractual relationship बन जाता है
3. Integration Tax
- वास्तविक adoption process में documentation देखना, library install करना, framework connect करना, और docs के बाहर की अतिरिक्त समस्याएं सुलझाना अनिवार्य होता है
- अक्सर tools के साथ conflict या अप्रत्याशित समस्याओं का सामना करना पड़ता है
- जब SaaS सिर्फ lowest common denominator को target करता है, तब modern stack या specialized environment में और ज्यादा काम करना पड़ता है
4. Local Development Tax
- SaaS service की local environment support अनिश्चित हो सकती है
- local emulator उपलब्ध है या नहीं, और testing के लिए stubs बनाना संभव है या नहीं, यह देखना पड़ता है
- कुछ features की पुष्टि के लिए cloud tunneling जैसी चीज़ों की जरूरत पड़ती है, जिससे environment setup जटिल हो जाता है
- production, staging, local के लिए अलग-अलग configuration branches बनना लगभग अपरिहार्य हो जाता है
5. Production Tax
- service integration के बाद production environment में नए तरह का बोझ पैदा होता है
- staging और PR preview environments में उपयोग की संभावना, API key management, monitoring, logging, alerts जैसी अतिरिक्त देखभाल की जरूरत होती है
- development environment में समस्या न हो, फिर भी वास्तविक production में ही दिखने वाली errors या inconsistencies के लिए तैयार रहना पड़ता है
- service stability बनाए रखने की जिम्मेदारी आखिरकार डेवलपर पर ही आ जाती है
निष्कर्ष
- आधुनिक SaaS का slogan है "पहिया दोबारा मत बनाओ", लेकिन हर नई service जोड़ने के साथ friction भी आता है
- किसी service को अपनाना सिर्फ साधारण integration नहीं, बल्कि एक contract है, जो dependency बढ़ाता है और architecture बदलता है. vendor lock-in अपरिहार्य है, और बदलने पर काफी code rewrite करना पड़ सकता है.
- इसलिए, ऐसे फैसलों को बार-बार दोहराने की बजाय शुरुआत से ही all-in-one platform चुनना ज्यादा प्रभावी है
- महत्वपूर्ण यह है कि डेवलपर वास्तव में कौन-सा software बनाना चाहता है
- Cloudflare, Supabase जैसे integrated platforms database, queue, image, storage को एक ही environment में उपलब्ध कराते हैं, जिससे ऊपर बताए गए tax का बोझ काफी कम हो जाता है.
- कई vendors के बीच switching (context switching) की जरूरत नहीं रहती
- API keys संभालने से जुड़ी समस्याएं कम होती हैं
- compatibility और environment-specific branching management की जरूरत न्यूनतम हो जाती है
- development और production environments में एक समान integration experience मिलता है
- ऐसे platforms ऐसा अहसास देते हैं मानो सब कुछ एक ही machine पर चल रहा हो, और code तथा services के बीच की दूरी घटाकर, वे किसी भी SaaS से न मिल पाने वाला development immersion ("Flow") वापस दिलाते हैं.
महत्वपूर्ण यह नहीं है कि आप कौन-सा framework या service चुनते हैं, बल्कि यह है कि आप जिस software को बनाना चाहते हैं और उसके flow को कैसे सुरक्षित रखते हैं
2 टिप्पणियां
Supabase को एक अच्छे उदाहरण के तौर पर पेश किया जा रहा है, तो फिर कौन-सी SaaS सेवाएं ऐसी हैं जिनसे बचना चाहिए?
Hacker News की राय
यह Adam Smith के “rent seeking(किराया-उगाही)” को आधुनिक दौर में बेहद बड़े पैमाने पर फैलाए गए रूप में देखने का नज़रिया है
मेरा मानना है कि ऐसी आर्थिक गतिविधि सामाजिक रूप से हानिकारक है, इसलिए इससे बचना चाहिए और इसे अपराध की श्रेणी में रखना चाहिए
दूसरी ओर, free software की चरम स्थिति भी आर्थिक रूप से समस्याग्रस्त है, क्योंकि software बनाने वाले के प्रयास का अनुपात उपयोगकर्ता को मिलने वाले मूल्य के बराबर नहीं होता
तर्क यह है कि software खरीदना और अलग से service contract करना, ये दोनों अलग-अलग हों और वास्तव में अलग मूल्य दें
SaaS में ये सब एक साथ बंध जाने से असली समस्या यह है कि service की तुलना में packaging असामान्य रूप से विकृत हो जाती है
अगर मैं इस बारे में इतना ही उत्साही होता, तो खुद SaaS बनाकर on-premise deployment·operations देने वाली कंपनी शुरू करता और इसे मौजूदा SaaS जैसी कीमत पर देता
अगर कंपनियाँ data पर नियंत्रण बनाए रखते हुए vendor lock-in से बच सकें, और फिर भी SaaS जैसी ही quality, guarantees और pricing दे सकें, तो वे बाज़ार पर कब्ज़ा कर सकती हैं
मैं हमेशा यह सोचता हूँ कि क्या सिर्फ binary देकर users को AWS या GCP, या cloudflare workers पर चलाने देना काफी नहीं होगा
मेरी नज़र में saas developer के रूप में आकर्षक है, लेकिन consumer के रूप में नापसंद, इसलिए मैं खुद एक ethical dilemma में पड़ जाता हूँ
अगर मैं software बेचूँ, तो अगर user उसे बिना अनुमति redistribute कर दे तो क्या होगा? saas की तरह distribution को control नहीं कर पाऊँगा
मैं foss(open source) का समर्थक हूँ, लेकिन जैसा आपने कहा, यह तरीका भी आर्थिक रूप से समस्याग्रस्त है
मैं GitHub Sponsors के ज़रिये license जारी करने जैसे तरीकों पर भी सोच रहा हूँ, और कुछ projects में authentication को SSPL रखना, या license खरीदने पर BSD/MIT में बदलने वाला मॉडल भी सोच रहा हूँ (पुराने redis जैसा)
लेकिन अगर मैं ऐसा मॉडल सच में लागू करूँ, तो क्या लोग वास्तव में खरीदेंगे, इस पर संदेह है; मैं दोनों तरीके support करने पर भी विचार कर रहा हूँ, लेकिन कोई साफ जवाब नहीं है, इसलिए सलाह चाहता हूँ
संदर्भ के लिए, मैंने ऐसे projects बनाए हैं जैसे कोई भी मुफ्त में cryptocurrency बना सके ऐसा tool, YouTube से blog लाने की सुविधा, और YouTube community व videos को Google Photos के विकल्प के रूप में इस्तेमाल करने वाला unlimited storage; साथ ही privacy सुधार पर भी सोच रहा हूँ। अगर monetization के ideas हों तो बताइए
ज़्यादातर SaaS में provider के नज़रिये से hosting, support, R&D जैसी लगातार लागतें आती रहती हैं
इसलिए यह ढाँचा क्यों “किराया-उगाही” है, इस तर्क से सहमत होना मुश्किल है
SaaS को पूरी तरह rent seeking नहीं कहा जा सकता; बात यह है कि software की “stickiness(चिपकाव, lock-in)” खुद स्वभावतः rent-seeking जैसी लगती है
ज़्यादातर SaaS कंपनियाँ stickiness चाहती हैं, लेकिन यह SaaS की अनोखी विशेषता नहीं है
मैं अपने SaaS product को उन ग्राहकों को बेचता हूँ जो उसे बाज़ार में उचित कीमत पर खरीदना चाहते हैं
vendor lock-in का एहसास आमतौर पर तब होता है जब कंपनी के अंदर पूछा जाता है, “हम NEWTHING tool क्यों नहीं अपना रहे?” और जवाब मिलता है कि हम पहले से Oracle, MS, IBM, Salesforce के साथ 5 साल के long-term contract में बंधे हैं, इसलिए कुछ नहीं कर सकते
फिर करीब 10 साल बाद सचमुच हालत यह हो जाती है कि आप उस vendor से पूरी तरह बंध जाते हैं और बदलना लगभग असंभव हो जाता है
अगर business 10 साल तक टिक गया है, तो यह शायद blessing है या फिर एक boring problem, लेकिन startup के शुरुआती चरण में अलग-अलग tools चुनने में समय बर्बाद न करके जल्दी एक platform चुनकर उसी पर ध्यान देना चाहिए
ऐसे मामलों में भी services को standardized interface से abstract करना अच्छा है
अगर abstraction पहले से हो, तो बाद में किसी दूसरी service पर जाने के लिए सिर्फ alternative implementation देना होगा
यह तरीका future-oriented है, लेकिन आजकल बहुत-सी कंपनियाँ ऐसी तैयारी नहीं करतीं
मेरा मानना है कि dependencies को कम से कम रखना product और business sustainability बढ़ाने वाले सबसे महत्वपूर्ण तत्वों में से एक है
मेरी पिछली नौकरी में मैं हमारे product में DocuSign-style electronic signature experience integrate करने का ज़िम्मेदार था
हमने DocuSign, Adobe जैसे बड़े vendors से बात की, लेकिन API restrictions इतनी थीं कि वे product और customer requirements के अनुरूप नहीं बैठते थे, इसलिए हमने अंततः इसे internally खुद बनाने का फैसला किया
आम तौर पर DocuSign जैसा tool खुद बनाना बुरा फैसला माना जाता, लेकिन हमारे product पर ग्राहकों का भरोसा पहले से था, इसलिए adoption barrier कम था
इसे खुद लागू करते समय शुरुआत में काफ़ी काम था, लेकिन जब वास्तविक customer-specific छोटे बदलावों की ज़रूरत पड़ी, तो हम तेज़ी से प्रतिक्रिया दे सके; अगर vendor इस्तेमाल किया होता, तो वही काम कहीं ज़्यादा भारी और झंझटभरा बन जाता, इसलिए खुद बनाना सही फैसला था
मुझे लगा कि लेखक कह रहा है कि SaaS vendor lock-in है, इसलिए इसे खरीदना ही नहीं चाहिए
लेकिन असल में मुख्य लेख में वह Cloudflare नाम के एक खास platform पर all-in जाने की सलाह दे रहा है
आखिर जो भी चुनो, सब किसी न किसी रूप में lock-in ही है, और open source·self-hosting में भी अगर विकल्प बदलो तो ढेर सारा code फिर से लिखना पड़ सकता है
सिर्फ vendor-dependent features का इस्तेमाल करना और “असली lock-in” एक जैसी बात नहीं है; lock-in तब होता है जब बदलने की लागत और समय, मौजूदा व्यवस्था में बने रहने से ज़्यादा हो
अगर software को loosely coupled और cohesive बनाया जाए, तो किसी खास हिस्से को बदलना आसान होता है
क्योंकि interface जितना सरल होगा, replacement भी उतना आसान होगा
इसलिए “सब lock-in है, तो चलो और पक्का एक platform से बंध जाएँ” वाला चुनाव developer को सुविधाजनक लग सकता है, लेकिन management के नज़रिये से यह अच्छी strategy नहीं है; कंपनी की flexibility और बदलने की क्षमता पर ध्यान देना चाहिए
business owner के नज़रिये से ऐसी solutions चुननी चाहिए जो कंपनी को flexibility और changeability दें; बिना किसी fallback के SaaS में बंध जाना मूर्खता है
शुरुआती चरण या बिना revenue के समय SaaS की बजाय platform इस्तेमाल करना फायदेमंद हो सकता है, और growth के बाद scale phase में पहुँचने पर लंबे समय की तकनीकी दिशा पर सोचना चाहिए
मैं cloudflare workers का अक्सर उपयोग करता हूँ, और code भी इस तरह लिख रहा हूँ कि वह कहीं भी portable रहे
wrangler devसे local run संभव है, और वास्तव में pure node/bun/deno पर भी बिना बड़े बदलाव के चल सकता हैOP(मूल लेखक) SaaS का पूरी तरह विरोध नहीं कर रहा (आखिर वह Cloudflare या Supabase जैसी as a service solutions की सिफारिश भी करता है), बल्कि उसका मुख्य बिंदु यह है कि बहुत सारे vendors के साथ contract और management करने की operational cost और relationship management का बोझ बहुत बड़ा होता है
vendor जितने कम हों, dependencies जितनी कम हों, operations उतने आसान होते हैं
वास्तव में हर feature को standard library से implement करना एक बहुत आदर्शवादी कल्पना है, लेकिन व्यवहार में यह बेहद कठिन है
मुख्य सुझाव यही है कि शुरुआत में कई services को मिलाने-जुलाने के बजाय एक platform आज़माओ
मुझे cloudflare पसंद होने का कारण यह है कि वह bindings को
fetchकी तरह standardize करता है, औरfetchमुझे web world में Unix pipe जैसा महसूस होता हैvendor lock-in से बचने के लिए एक ही platform पर पूरा all-in कर लेना, और इस तरह खुद को और ज़्यादा एक ही company से बाँध लेना, अपने आप में एक irony है
क्योंकि SaaS में भी fragmentation cost(“tax”) होती है
बल्कि यह चर्चा open source की वकालत के अधिक करीब लगती है
open source और self-hosted model में लेख में बताए गए ज़्यादातर “tax(खोज, signup, integration, local development से जुड़ी लागत)” समाप्त हो जाते हैं
मेरा मानना है कि open source का production tax(operational burden) ecosystem activation या plugin, module ecosystem के ज़रिये हल किया जा सकता है
(religion और cult के फर्क की तरह) अगर आप data को standard format में export करके निकल सकते हैं, तो वह vendor lock-in नहीं है
ग्राहक अपने data पर अधिकार मिलने पर कम फँसा हुआ महसूस करते हैं, लेकिन समस्या यह है कि बहुत-सी SaaS services यह संभव ही नहीं बनातीं
अभी मैं मुख्य रूप से MIT के तहत public distribution करता हूँ, और महत्वपूर्ण चीज़ों को private रखता हूँ
SaaS की सीमा यह है कि software की “लगभग 0 के करीब marginal cost” से मिलने वाले लाभ का फायदा ग्राहक नहीं उठा पाते
SaaS operator कुछ हद तक इस लाभ को reflect करते हुए pricing कम कर सकता है, लेकिन जब users काफ़ी ज़्यादा हो जाएँ और प्रति-इकाई कीमत ऊँची हो, तब अंततः SaaS उपयोगकर्ता नुकसान में रहते हैं
लेकिन startup के शुरुआती चरण में सब कुछ खुद बनाना एक लापरवाह फैसला है, और “survival” तथा “initial cost minimization” के चरण में SaaS एक बेहद समझदारी भरी strategy है
business के बढ़ने और SaaS के रोज़मर्रा के workflow में गहराई से जम जाने के बाद ही lock-in, migration, switching cost जैसी समस्याएँ सामने आती हैं
मुझे लगता है कि SaaS की समस्या भी अंततः सफलता का एक side effect है
इसी वजह से ऐसे SaaS models इतने अधिक हैं
pension की तरह recurring revenue आता है, और ऊपर से pricing power भी मिलती है, इसलिए यह business model बेहद आकर्षक है