जो स्केल न हो, वही करो — और फिर सचमुच उसे स्केल मत करो

 (medium.com/@derwiki)
4 पॉइंट द्वारा GN⁺ 2025-08-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Paul Graham के “ऐसे काम करो जो scale न हों” विचार से शुरू करते हुए, अब GPT-सहायित development environment की वजह से काम को वास्तव में बहुत छोटे स्तर पर ही पूरा किया जा सकता है
  • अब छोटे पैमाने या व्यक्तिगत उपयोग के लिए सरल प्रोजेक्ट बनाए जा सकते हैं, और उन्हें ज़रूरी नहीं कि आगे growth या business में बदला जाए
  • वास्तविक उदाहरण के तौर पर Slack community, postcard mailer, और नियत समय reminder app जैसे प्रोजेक्ट व्यक्तिगत या छोटे समूहों के लिए बनाकर संतोष और उपयोगिता दोनों मिले
  • AI tools की प्रगति से छोटे, customized software बनाना लागत और गति—दोनों के लिहाज़ से बहुत आसान हो गया है, और छोटा होना ही कई बार उद्देश्य है
  • scale करने के दबाव से बाहर निकलकर कुछ छोटा, उपयोगी और बिल्कुल अपनी ज़रूरत के मुताबिक बनाकर वहीं रुक जाने की आज़ादी मिल सकती है

पृष्ठभूमि: ‘ऐसे काम करो जो scale न हों’ और समय का बदलाव

  • लगभग 10 साल पहले Paul Graham ने “Do things that don’t scale” का विचार रखा था
  • इस विचार का मतलब था कि शुरुआत में हाथ से किए जाने वाले छोटे प्रयोगों और व्यक्तिगत approach से शुरू करो, फिर धीरे-धीरे scale करने का तरीका खोजो
  • लेकिन हाल के GPT-आधारित tools की वजह से अब सिर्फ “शुरुआती काम” करके रुक जाना भी काफ़ी है, और कई बार वही सबसे बेहतर है
  • किसी प्रोजेक्ट को शुरू करने की लागत और समय बहुत कम हो गए हैं, और हर idea का business बनना अब ज़रूरी नहीं रहा
  • सिर्फ अपने लिए या अपने किसी छोटे, प्रिय समूह के लिए बनी सेवा भी पर्याप्त उद्देश्य रखती है

ऐसा Slack जिसे बड़ा नहीं होना चाहिए

  • लेखक लगभग 100 लोगों वाले एक Slack workspace को चलाते हैं
    • वास्तव में हर हफ़्ते सक्रिय बातचीत करने वाले लोग सिर्फ 15~20 के आसपास हैं
    • इससे अपनापन और निजी माहौल बना रहता है, और Twitter जैसे सार्वजनिक प्लेटफ़ॉर्म की तुलना में अधिक गहरी बातचीत संभव होती है
  • इसे और बड़ा बनाया जा सकता है, लेकिन scale करते ही माहौल टूट जाएगा और निकटता गायब हो जाएगी
    • 1,000 लोगों तक ले जाने की भी ज़रूरत नहीं है
    • जैसे-जैसे अनजान लोग बढ़ेंगे और यह पता न हो कि कौन सुन रहा है, बातचीत भी कम हो जाएगी
  • कुछ चीज़ें सिर्फ छोटे होने की वजह से ही संभव होती हैं

PostcardMailer: छोटा, और बेहद सरल

  • कुछ साल पहले लेखक ने एक छोटी साइट (PostcardMailer) बनाई, जो Instagram पर फोटो पोस्ट करने पर उनकी माँ को postcard भेजती थी
    • यह फोटो और caption लेकर postal API के ज़रिए माँ को भेज देती थी
  • Instagram API policy बदलने के बाद यह तरीका बंद हो गया, तो इसे फोटो upload वाले तरीके से फिर बनाया गया
    • इसका इस्तेमाल एक दोस्त और कुछ Orange Site(Hacker News) users ने किया
    • बाद में spam और दुरुपयोग की चिंता के चलते account management सीमित कर दिया गया
    • Heroku की सेवा बंद होने से साइट को बनाए रखना छोड़ा गया, और अंततः इसे email-आधारित service में बदल दिया गया
  • अब iPhone से mom@postcardmailer.us पर email से फोटो भेजने पर माँ को postcard भेज दिया जाता है
    • यह private है, इसमें login या password नहीं है
    • बाज़ार में postcard भेजने वाली बहुत सी साइटें हैं, लेकिन ठीक वैसा जैसा चाहिए, वैसा काम करने वाली यही एक service है

Landline Pill Reminder: सिर्फ माँ के लिए reminder app

  • एक समय लेखक की माँ को तय समय पर दवा लेनी होती थी
    • उनकी माँ के पास smartphone नहीं था, और अक्सर साधारण flip phone भी बंद रहता था
  • भरोसेमंद संपर्क के साधन सिर्फ डाक या घर का landline थे
  • इसलिए Twilio API से दिन में 3 बार voice call करने वाला एक छोटा app बनाया गया
    • इसमें रिकॉर्ड की गई आवाज़ कहती थी, “दवा लेने का समय हो गया है”
    • 10 मिनट बाद एक और कॉल करके पुष्टि भी माँगी जाती थी
  • इसे बनाने की लागत लगभग शून्य थी और यह कुछ ही दिनों में तैयार हो गया
    • अगर इसे scale किया जाता, तो दूसरों के लिए support, ज़िम्मेदारी और कानूनी जोखिम भी आते, लेकिन सिर्फ माँ के लिए बना solution सबसे सुरक्षित और असरदार था

पैटर्न (सीख)

  • अपनी ज़िंदगी में मायने रखने वाली ज़रूरत को पहचानो
  • उसका सबसे छोटा और सरल solution बनाओ
  • scale करने की इच्छा को जितना हो सके दबाओ
  • तैयार solution का आनंद लो
  • पहले scale करना केंद्र में होता था, लेकिन अब ‘छोटा होना’ खुद एक उद्देश्य हो सकता है
    • AI जैसे सहायक tools की वजह से personalized software बनाने की लागत और मेहनत बहुत कम हो गई है
    • 1 व्यक्ति या बहुत छोटे user group के लिए बनी service सबसे सही विकल्प हो सकती है

निष्कर्ष: ‘छोटेपन’ की कीमत

  • आज के tools और environment की असली विलासिता/सुविधा सिर्फ speed, cost या AI नहीं है, बल्कि यह आज़ादी है कि आप रुक सकते हैं
  • अपने लिए कुछ छोटा, उपयोगी और बिल्कुल फिट बैठने वाला बनाकर, बिना ज़बरदस्ती growth के पीछे भागे भी पूरी संतुष्टि मिल सकती है
  • scale के जुनून वाले दौर में, ठीक-ठाक संतोष के साथ रुक जाने की शांत संतुष्टि ही एक नई value है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-17
Hacker News राय

  • यह जिज्ञासा तो रहती है कि चीज़ कितनी बड़ी हो सकती है, लेकिन किसी बिंदु पर—शायद 1,000 लोगों से पहले ही—ऐसा लगता है कि माहौल टूट जाता है, अपनापन गायब हो जाता है, नाम भी परिचित नहीं रहते, यह समझना मुश्किल हो जाता है कि पोस्ट कौन देख रहा है, इसलिए बातचीत भी कम हो जाती है, यानी growth खुद ही उलटा बुरा असर डालने लगती है, लगता है कि यह छोटी होने की वजह से अच्छी तरह काम करती है, मेरा मानना है कि Facebook जैसे social network में भी यही बात लागू होती है, 2005~2010 के आसपास Facebook वह जगह था जहाँ कॉलेज, हाई school और office के दोस्त इकट्ठा होकर खुलकर अपने विचार साझा करते थे और दिलचस्प links बाँटते थे, लेकिन जैसे-जैसे जान-पहचान के लोग बढ़े और कम नज़दीकी लोग friend list में जुड़ने लगे, माहौल पूरी तरह बदल गया, किसी न किसी मोड़ पर हर किसी ने यह अनुभव किया है कि जब कोई ऐसा व्यक्ति, जो आपका क़रीबी भी नहीं है, आपकी post से नाराज़ हो जाए या राय टकरा जाए, तो आप धीरे-धीरे साझा करना कम कर देते हैं

    • याद है Facebook पर मैंने कोई बहुत गंभीर बात भी नहीं, बस एक गाली लिख दी थी, तो दादी ने message करके उसे हटाने को कहा था, उसकी जगह मैंने दादी को ही block कर दिया, त्योहारों पर ही मिलना ज़्यादा बेहतर था, और लगता है दादी को कभी इस बात का पता भी नहीं चला
    • इस phenomenon के लिए वास्तव में 'Context Collapse' नाम का एक शब्द है, यह बताता है कि social media अलग-अलग social contexts (जैसे: workplace, school, family आदि) में अपने अलग रूप दिखाने के बजाय एक ही online persona थोप देता है, संबंधित लिंक
    • याद है कि मैं अपने दोस्तों में Facebook पर सबसे आख़िर में जुड़ा था, IRC पर बड़े हुए old-school internet user के तौर पर अपना असली नाम और फोटो किसी ढीले-ढाले PHP site पर डालना—वह भी किसी Harvard वाले ने बनाई हो—मुझे बहुत अजीब लगा था, लेकिन जब सब लड़कियाँ उसे इस्तेमाल कर रही थीं, तो आखिरकार सब उसी तरफ चले गए। वही पल इतिहास बन गया
    • एक समय ऐसा आया जब जैसे सबको एक साथ समझ आ गया कि Facebook अब कुछ साझा करने की जगह नहीं रहा, बल्कि competition का मैदान बन गया है, और तभी सबने sharing बंद करके 'curation' शुरू कर दी
    • 2008 के आसपास Facebook सच में अच्छा था, ऐसा लगता था जैसे असल ज़िंदगी के दोस्तों के साथ समय बिता रहे हों, लेकिन परिवार के लोग जुड़ते ही उसका माहौल extended family dinner जैसा हो गया

  • अपने लिए कुछ बनाने की प्रक्रिया मज़ेदार होती है, मैं भी ऐसा करता हूँ, बस यह बताना चाहता हूँ कि मूल लेख संस्थापकों—यानी कंपनी बनाने वालों—के लिए लिखा गया था

    • यह खास तरह की कंपनियों, ख़ासकर tech startup, के बारे में बात है, मैं कहना चाहता हूँ कि startup की तरह सिर्फ growth के पीछे भागते हुए घाटा सहने के बजाय, जितनी जल्दी हो सके revenue कमाने वाली 'कंपनी' बनाने का नज़रिया ज़्यादा ज़रूरी है, मेरा मानना है कि ऐसी कंपनी बननी चाहिए जो ज़रूरी नहीं कि तेज़ी से बढ़े, लेकिन मुनाफ़ा कमा सके
    • हाँ, मानता हूँ कि मूल लेख की सलाह खुद founder-केंद्रित थी, मैं बस इस बढ़िया वाक्यांश को थोड़ा मोड़कर देखना चाहता था, इसका इस्तेमाल काफ़ी काम का है
    • अगर आप अपनी समस्या हल करने के लिए कुछ बनाते हैं, और वह ऐसी समस्या निकलती है जिससे दूसरे लोग भी जूझ रहे हैं और हल करने की कोशिश करके असफल हो चुके हैं, तो वहाँ demand हो सकती है, और अगर समस्या काफ़ी परेशान करने वाली है, तो लोग उसके लिए पैसे देने को भी तैयार हो सकते हैं, दरअसल ऐसी समस्याएँ B2C से ज़्यादा B2B में मिलती हैं, अक्सर व्यक्तिगत समस्या B2B तक फैल जाती है
    • 'Startup' शब्द को अक्सर 'तेज़ growth के लिए डिज़ाइन की गई छोटी कंपनी' के रूप में परिभाषित किया जाता है

  • Robin Sloan ने कुछ साल पहले इसी विषय पर एक लेख लिखा था, मेरा मानना है कि हाल के समय की सबसे सकारात्मक बातों में से एक यह है कि अब कोई भी programming language या विशेष knowledge के बिना भी कोई छोटी-सी चीज़ बनाकर आनंद ले सकता है, उसका बहुत ज़्यादा revolutionary होना भी ज़रूरी नहीं है, संबंधित लेख

  • मैंने Claude Code की मदद से role-playing game के लिए hexmap बनाने वाला एक छोटा web app बनाया, ऐसे बहुत से मिलते-जुलते sites हैं और ज़्यादातर मुफ़्त भी हैं, यहाँ तक कि कई में ऐसी features भी हैं जो मेरे app में नहीं हैं, लेकिन मेरा app ठीक उसी तरह काम करता है जैसा मैं चाहता हूँ, जैसे tile terrain पर नदी और जंगल चढ़ाकर edit करना, तरह-तरह के settlement icons, hills/mountains के ज़्यादा variants वगैरह—यानि वे सब चीज़ें शामिल हैं जो मैं चाहता था, और जब भी कोई feature चाहिए, मैं बस उसे जोड़ सकता हूँ, किसी और के app को देखकर "चलो, जो है सो है" कहने की ज़रूरत नहीं, क्योंकि यह मेरे निजी इस्तेमाल के लिए है, इसलिए scalability, security या monetization जैसी बातों की चिंता करने की ज़रूरत नहीं, असली development में कुल मिलाकर एक-दो घंटे ही लगे, वह भी दो दिनों में बाँटकर AI से लिखवाया

  • “Do things that don’t scale” startup दुनिया की एक कहावत है, लगता है यह Airbnb या Y Combinator के शुरुआती दिनों से चली आ रही है, कुछ दिन पहले यह फिर HN पर आई थी संबंधित लेख

    • दिलचस्प timing है, यह मैंने पिछले weekend लिखा था और इस हफ़्ते HN लगभग देखा ही नहीं
    • क्योंकि Google search में सबसे ऊपर यही लेख आता है, इसलिए मुझे लगता है कि मूल लेख की credibility थोड़ी कम हो जाती है

  • मैं इस बात से सहमत हूँ कि हर चीज़ का बड़ा होना ज़रूरी नहीं, लेकिन ChatGPT और इस हफ़्ते के विषय के बीच कोई ख़ास संबंध है, ऐसा मुझे नहीं लगता

    • यह कुछ वैसा है जैसे पहले सिर्फ injection molding संभव था, और अब 3D printer आ गए हों
    • लेख में दिए गए उदाहरण भी वास्तव में LLM (large language model) से पहले के समय के हैं
    • शायद इसने ChatGPT से coding करके नहीं देखी है

  • Robin Sloan का "apps can be home-cooked" वाला लेख recommend करता हूँ संबंधित लिंक

  • यह लेख मुझसे सच में resonate करता है, इसी वजह से मैंने software consulting का काम छोड़ दिया, अब आगे चलकर आप LLM से कहेंगे कि जो कुछ चाहिए वह सब लिख दे, और वह tech stack, hosting, integration तक संभाल लेगा, "Discord alternative ढूँढो" वाली दुनिया "मेरे और मेरे दोस्तों के लिए Discord clone बना दो" वाली दुनिया में बदल रही है, code quality अब उतनी मायने नहीं रखेगी, क्योंकि अब उसे लाखों users इस्तेमाल नहीं करने वाले

    • मैं इससे सहमत नहीं हूँ, ऐसा अनुभव LLM से पहले भी संभव था, ज़्यादातर products के open source alternatives पहले से मौजूद थे, और कई बार उनका install और deployment LLM से भी आसान होता था, ऊपर से updates वगैरह भी मिलते रहते थे, बस लोग install, deployment और security maintenance की ज़िम्मेदारी नहीं लेना चाहते, इसलिए ऐसे service के लिए थोड़ा-बहुत भुगतान करना उन्हें कहीं बेहतर लगता है, समस्या code लिखने की नहीं थी

  • Maciej Ceglowski की मशहूर रचना “Barely Succeed: It’s Easier” याद आ गई संबंधित YouTube लिंक

  • मूल रूप से सवाल यही है कि क्या 'scale' सच में कभी इतना महत्वपूर्ण लक्ष्य था?