बिना लॉगिन फीचर के प्रोडक्ट लॉन्च क्यों करना चाहिए

• लॉगिन implementation को टालने से

→ development speed तेज़ होती है, और code complexity कम होती है

→ user onboarding के समय friction कम होता है

→ hacking attack surface कम होता है

→ संभावित SEO फ़ायदे भी शामिल होते हैं

• लेखक के सफल 2 web products में लॉगिन नहीं था

• जिस प्रोडक्ट पर अभी काम हो रहा है, वह रोज़ 50,000 views / महीने $2K revenue देता है, लेकिन लॉन्च के 4 साल बाद जाकर ही उसमें लॉगिन जोड़ा गया

[rondo]

वाह.. लॉगिन के बिना unique link के ज़रिए user को identify करने का तरीका तो मैंने कभी सोचा भी नहीं था, काफ़ी कमाल है, हाहा

इस बार के side project को बिना लॉगिन के implement करने की कोशिश करूँगा, हेहे

[fantasyu]

हमने व्यक्तिगत जानकारी को संभालने के बोझ की वजह से सबसे पहले जो फीचर शुरुआती चरण से बाहर किया, वह सदस्यता/लॉगिन था। फीचर implementation का बोझ भी था, लेकिन उससे भी बढ़कर संचालन या व्यक्तिगत जानकारी को संभालने के लिए हमारे पास लोग नहीं थे, इसलिए यह भारी लग रहा था। लॉगिन के बाद दिए जा सकने वाले कई फीचर और सुविधाओं को लेकर हमने काफी सोचा, लेकिन आखिरकार उसे हटाकर ही पहले चरण में आगे बढ़ रहे हैं.

[xguru]

बिलकुल, मुझे लगता है यह एक शानदार चुनाव है। अगर मौका मिले, तो आप जो प्रोडक्ट बना रहे हैं उसे Show GN में भी ज़रूर परिचय कराइए! हाहा

[budlebee]

संभावित SEO लाभ शामिल हैं -> लगता है इस हिस्से में टाइपो है

[xguru]

अरे हाँ, मैंने इसे जल्दी से ठीक कर दिया है ;)

[sixmen]

हमारी कंपनी का प्रोडक्ट शुरुआत में बिना लॉगिन के शुरू हुआ और अच्छी तरह बढ़ा भी, लेकिन बाद में जब प्रोडक्ट इस तरह विकसित हुआ कि लॉगिन ज़रूरी हो गया, तब यूज़र्स को लॉगिन के लिए प्रेरित करना मुश्किल लगा। लगता है कि यह प्रोडक्ट के अनुसार चुना जा सकने वाला एक विकल्प है.

[xguru]

हाँ, लगता है कि बाद में login की तरफ सहज रूप से प्रेरित करना ही असली स्किल है। ऐसे मामलों के examples ज़्यादा share हों तो अच्छा लगेगा.

[nicewook]

• मुझे पूरी तरह यक़ीन नहीं है, लेकिन क्या login फ़ीचर को भी OAuth2 सहित किसी तरह template की तरह बनाया जा सकता है?

• ऐसा लगता है कि सिर्फ़ OAuth2 होने पर भी user onboarding का बोझ काफ़ी कम हो सकता है.

• क्या hacking attack surface में कमी का मतलब यह समझा जाए कि इसमें व्यक्तिगत जानकारी संग्रहीत नहीं होती, इसलिए शुरू से ही hack करने लायक चीज़ें कम होती हैं?

[budlebee]

मूल लेख में "Evil-doers are much less likely to break into your house if there is nothing of value inside" कहा गया है, इसलिए इसका सही मतलब यही है कि चुराने लायक कुछ नहीं है, इसलिए यह सुरक्षित है।

[nicewook]

धन्यवाद। मैं मूल लेख तक नहीं देख पाया था, लेकिन अब बात स्पष्ट हो गई है।

[xguru]

हाँ, शायद उनका मतलब यह था कि सर्वर पर कुछ भेजना पड़ेगा, पासवर्ड स्टोरेज जैसी चीजें करनी पड़ेंगी, इसलिए उन्होंने उस हिस्से की बात की होगी.

मेरी नज़र में भी, डेवलपमेंट की तरफ आजकल Passport.js जैसी चीजें बहुत कुछ संभाल लेती हैं, इसलिए डेवलपमेंट वाला हिस्सा बहुत बड़ा बोझ नहीं लगता.

लेकिन ID होने पर सर्विस प्लानिंग वाला हिस्सा काफ़ी बढ़ जाता है. बिना ID के भी फीचर्स आज़माने देना शुरुआती user traction बनाने के लिए कहीं ज़्यादा बेहतर लगता है. व्यक्तिगत रूप से, मैं नए बने साइट्स पर OAuth से लॉगिन करना भी थोड़ा टालता हूँ. ^^;

[nicewook]

आपकी बात सुनकर लगता है कि OAuth भी मेरी निजी जानकारी बिखेरने जैसा ही काम है। मैं तो वैसे भी इस मामले में काफ़ी निश्चिंत रहता हूँ...;;;

[xguru]

यह जिस तरह के प्रोडक्ट पर निर्भर करता है, लेकिन..

अगर ऐसी service है जिसमें login बिल्कुल ज़रूरी नहीं है, तो मुझे लगता है कि उस feature को फिलहाल छोड़कर जल्दी develop करके launch करना और बाद में जोड़ना सही है। हमारे यहाँ की services अक्सर बिना ज़रूरत बहुत सारी दूसरी personal information लेती हैं।

एक बात और जोड़ूँ तो.. लेख में कहा गया है कि email भी save नहीं करना चाहिए, लेकिन feature notifications या newsletter भेजने के लिए कम से कम email address को optional रूप में लेना ठीक लगता है।