सबसे दुखद "Just Ship It" कहानी (2020)

 (kitze.io)
1 पॉइंट द्वारा GN⁺ 2024-07-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2018 में शुरू किए गए side project का MVP कुछ ही दिनों में तैयार हो गया था, लेकिन public release को लगातार टालते-टालते वह 2 साल तक unreleased project बन गया
  • देरी के केंद्र में “बस एक चीज़ और” वाला बार-बार लिया गया फैसला था, और React Native व Expo तक सीखते हुए product scope बढ़ता गया
  • वही समस्या हल करने वाला competitor app धीमा और buggy था, लेकिन वह पहले ही launch हो चुका था, users और community जुटा चुका था, और हर हफ्ते improve हो रहा था
  • 30-day trial के बाद competitor app के लिए payment करते समय, hard drive में ही पड़ा अपना app व्यावहारिक रूप से मृत product बन गया
  • 2024 update में बताया गया कि 2022 में productivity app Benji आखिरकार launch किया गया, और निष्कर्ष भले ही घिसा-पिटा लगे, लेकिन बात पहले ship करने के करीब है

कुछ ही दिनों में बने MVP को 2 साल तक release न कर पाने की वजह

  • 1 जनवरी 2018 को app development शुरू किया गया, और MVP कुछ ही दिनों में तैयार हो गया
  • 0.0.1 alpha version भी public करने लायक स्थिति में था, लेकिन हर बार “बस एक feature और”, “बस एक screen और” के कारण launch टलता गया
  • यह सोचकर कि “proper native mobile app नहीं होगा तो लोग इस्तेमाल नहीं करेंगे”, React Native सीखने और कुछ महीने और लगाने का फैसला किया गया
  • इसके बाद 2 साल तक web platform, React Native, Expo, GraphQL, tech stack को लेकर उलझन, दूसरे projects पर switch करना, Sizzy जैसे दूसरे apps launch करना, passion खोना और फिर वापस पाना—यह सब दोहराता रहा
  • आखिरकार development रोक दिया गया, और उस app को launch करने का विचार भी छोड़ दिया गया

वही समस्या हल करने वाला app मिलने का क्षण

  • समय बीतने के बाद खुद उस app को लगातार इस्तेमाल करते हुए महसूस हुआ कि कई जरूरी features चाहिए, और फिर से development शुरू करने या कोई alternative खोजने की स्थिति बन गई
  • alternative app का landing page देखते ही यह भावना जोर से आई कि जिस समस्या को वह हल करना चाहता था, उसे कोई और पहले ही हल कर चुका है
  • पहले अपने app का video कुछ लोगों को भेजा था, इसलिए इतना शक भी हुआ कि कहीं वह video share तो नहीं हुआ, क्योंकि features और समस्या को देखने का नजरिया बहुत मिलता-जुलता लगा
  • लेकिन competitor app का होना उनकी गलती नहीं, बल्कि यह स्वीकार किया कि वह खुद बहुत धीमा था और समय पर launch नहीं कर पाया

perfection से पहले launch करने वाला competitor app

  • account बनाते और help center videos देखते समय, implementation का तरीका smart लगने वाले हर क्षण में उसे यह अहसास होता रहा कि वह खुद competitor है
  • 2 साल तक वह सोचता रहा कि उसका app अधूरा, buggy और features में कम है, इसलिए कोई इस्तेमाल नहीं करेगा; लेकिन competitor app इस्तेमाल करने पर उसे लगा कि यह आकलन गलत था
  • competitor app भी कई सालों से develop हो रहा था, फिर भी वह अभी भी धीमा, buggy और बहुत polished नहीं था
  • mobile app इतना अच्छा नहीं था कि sync में 10 seconds लगते थे, लेकिन वह पहले से launched product था और users अगले update का इंतजार कर सकते थे
  • todo list बड़ी होने के बावजूद, वे हर हफ्ते releases जारी रख रहे थे और app व community साथ-साथ grow कर रहे थे

payment के बाद बचा सबक

  • 30-day trial खत्म होने के बाद credit card details डालीं, और वह सिर्फ subscriber नहीं बल्कि fan बन गया
  • payment notification एक ऐसा अनुभव बन गया जो बार-बार याद दिलाता था कि वह खुद launch नहीं कर पाया
  • इसी क्षण उसने स्वीकार किया कि उसका अपना app आधिकारिक रूप से मर चुका है
  • इसी स्थिति में मौजूद ज्यादातर लोगों ने शायद अपना project शुरू किए कुछ ही हफ्ते हुए होंगे, इसलिए उन्हें वही गलती टालनी चाहिए
  • अगर “बस एक चीज़ और” authentication, payments, boilerplate को फिर से बनाने का काम है, तो वही जाल है; बाद में उस जाल को कम करने के लिए Zero To Shipped बनाया गया

2024 update: आखिरकार Benji launch

  • 2024 update के मुताबिक, 2022 में आखिरकार Benji launch किया गया
  • launch की वजह यह थी कि कोई भी competitor app उसके vision के पर्याप्त करीब नहीं था
  • वह जिस app को चाहता था, वह Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips आदि को मिलाकर बना रूप था
  • Benji में एक public timeline भी है, जहां लोग अपनी life improve करते हुए success और achievements share करते हैं
  • घिसा-पिटा लगे तब भी सांस लें, और फिर भी Just Ship It करें

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

1 टिप्पणियां

 
GN⁺ 2024-07-05
Hacker News की रायें

  • ऐसी “तब बस रिलीज़ न करने की वजह से खत्म हुई कहानी” में एक बड़ा संकेत होता है: कभी-कभी बनाए जा रहे ऐप की वैल्यू उन तकनीकी डिटेल्स में होती है जिनमें जल्दबाज़ी नहीं की जा सकती, और ऐसे में “बस रिलीज़ कर दो” जवाब नहीं होता
    सॉफ्टवेयर इंजीनियर/आर्किटेक्ट का काम मैनेजमेंट के “बस बाहर निकालो” वाले दबाव को जितना हो सके झेलना भी है। अगर यह आपका अपना प्रोडक्ट नहीं है और रिलीज़ से आपको व्यक्तिगत फायदा नहीं होने वाला, तो अगर ज्यादा समय लगाने से ज्यादा प्रोफेशनल नतीजा आता है, समय लगाना चाहिए। आप कोई ऑटोमैटिक मशीन नहीं हैं जो JIRA टिकट लेकर जितनी जल्दी हो सके घटिया कोड उगल दे; ऐसे लगातार काम करने से मानसिक थकान होती है और आखिर में burnout आता है
    अगर कंपनी में आपकी equity नहीं है, तो कंपनी का मुनाफा maximize करना आपका काम नहीं है; आपका काम अच्छा software बनाना है जिसे आप रिज़्यूमे में बिना शर्म के डाल सकें। किसी मनमानी deadline को फिर से पूरा कर लेने की राहत सिर्फ short-term negative motivation है और टिकती नहीं, इसलिए ऊपर से आने वाले दबाव को झेलकर सही ढंग से बनाना चाहिए। निकाले भी गए तो आजकल वैसे भी job change ही ऊपर जाने का रास्ता है

    • “अगर कंपनी में equity नहीं है तो profitability की चिंता करने की जरूरत नहीं” सॉफ्टवेयर डेवलपर की seniority की कमी दिखाने वाला खराब रवैया लगता है। अगर वह non-profit नहीं है, तो कंपनी के हर सदस्य को profitability में योगदान देना चाहिए
      हालांकि profitability का मतलब “बस रिलीज़ कर दो” नहीं है। अगर कोई कंपनी दोनों को अक्सर गड्ड-मड्ड करती है, तो यह management की तरफ seniority की कमी का संकेत है
      डेवलपर का काम “अच्छा software” बनाने से ज्यादा अच्छा product बनाना है। अच्छे product के लिए आम तौर पर अच्छे software की जरूरत होती है, लेकिन हमेशा नहीं; और बेहतरीन product के पीछे खराब software भी कई बार होता है। product, sales और development के बीच तनाव का नतीजा ऐसे समझौतों में होना चाहिए जो short-term, medium-term और long-term value को maximize करें। डेवलपर को समझना चाहिए कि किन चीजों को rough तरीके से किया जा सकता है, कंपनी की प्राथमिकताएं क्या हैं, और कब समझौता न करके अच्छा software बनाना चाहिए
      जो डेवलपर software quality पर कभी समझौता नहीं कर पाता, वह उन मौकों पर भी ताकत खो देता है जब सच में समझौता नहीं करना चाहिए
    • पहले यह देखना चाहिए कि development क्यों कर रहे हैं। यह hobby, आनंद या code की खूबसूरती के लिए भी हो सकता है, लेकिन ज्यादातर मकसद यह होता है कि software किसी का जरूरी काम कर दे
      इसलिए पहली प्राथमिकता users के लिए value बनाना और जितना संभव हो उतनी efficiently develop करना है। ऐसा software जिसका कोई उपयोग न करे, उसका मतलब ही क्या है
      डेवलपर का काम अच्छा software बनाना नहीं, बल्कि users को value deliver करना है। अपने career में मैंने उल्टा ज्यादा देखा है: डेवलपर over-engineering के नशे में, उन features से code फुलाते हैं जिनकी किसी को जरूरत नहीं, और ऐसे future development के लिए code बढ़ाते हैं जो कभी आया ही नहीं। इसलिए मुश्किल काम minimal बने रहना है, और लगता है मूल लेख भी यही कह रहा है
    • यह पूरी टिप्पणी ऐसी पढ़ी जाती है जैसे कोई व्यक्ति सहकर्मियों के रिश्ते को पूरी तरह विरोधी मानता हो और उसमें भरोसा लगभग न हो। काफी थकाने वाला लगता है
    • मैं एक startup के शुरुआती कर्मचारियों में से था, और अगर हमने समझौता न किया होता तो शायद कंपनी आज मौजूद ही न होती। ऐसा approach उन बड़ी स्थापित कंपनियों में ही चलता है जहां team impact का परिणामों पर असर सीमित होता है
      छोटे और मध्यम आकार की कंपनियों में निश्चित रूप से समझौता जरूरी है, और सर्वोत्तम business outcome तक ले जाने वाला चुनाव करना भी professional का काम है
      कई डेवलपर managers, PMs और designers की कई layers से “protected” रहते हैं, इसलिए business side से उनका जुड़ाव कमजोर होता है। product जल्दी निकालने पर feedback भी जल्दी मिलता है, और यह assess करने का मौका भी मिलता है कि implementation assumptions से मेल खाती है या नहीं। दबाव में “perfect” solution deploy करके फिर उसे दोबारा लिखने की तुलना में यह कम stressful था
      मेरी current job में developer के तौर पर मेरा काम complexity कम करना और PM व designer से initial plan को कम से कम करवाना है। तब arbitrary deadlines भी कम stressful होती हैं और delays का असर भी छोटा होता है
    • यह satire जैसा लगता है। “अगर यह आपका काम नहीं है तो गलत काम करो, और अगर आपका काम है तो जल्दी रिलीज़ करो”, “काम यह है कि resume में डालकर अच्छा महसूस हो” जैसी प्रभावशाली पंक्तियां चलती जाती हैं
      इसमें मूल्यवान बात बस इतनी है कि किसी खास workplace से बहुत ज्यादा चिपके न रहें और fired होने की जरूरत से ज्यादा चिंता न करें, लेकिन उसके लिए दी गई वजह भी मुझे गलत लगती है। हैरानी होती है कि ऐसे antagonistic attitude वाले लोगों के साथ सच में काम करना पड़ सकता है
      लगता है कुछ लोगों को game theory के गलत quadrant में रहना पसंद है

  • “मुझे शक हुआ कि मेरे app का video इन लोगों को किसने share किया। क्योंकि वे सचमुच वही problem solve कर रहे थे” वाला हिस्सा देखकर मुझे पहले मिले एक व्यक्ति की याद आई जिसके पास ठीक-ठाक app idea था
    उसने मुझसे app मुफ्त में code करने को कहा और revenue share करने को बोला। जब मैंने पूछा कि वह खुद क्या contribute करेगा, तो उसने कहा कि वह company “चलाएगा”, और उसका 50% हिस्सा इसलिए है “क्योंकि idea उसी ने निकाला”। इसलिए मैंने कहा कि उसे 6 महीने का head start दूंगा, और अगर तब तक वह market में नहीं ला पाया तो मैं खुद बना दूंगा

    • एक समय मैं indie game project में शामिल था। idea साधारण था, लगभग एक खराब game जैसा, लेकिन हम तीनों उस क्षेत्र में software development experience चाहते थे
      तीन में से दो लोग बस बैठकर उसका रूप बनाना शुरू कर चुके थे, लेकिन तीसरे ने टूटा हुआ code SVN में डाला, पूरे idea का श्रेय खुद को देते हुए design document बनाया, फिर meeting बुलाकर कहा कि वह game designer है और अगर हम कहीं और game बनाएंगे तो वह हम पर lawsuit करेगा। सच में contribute कर रहे दोनों ने एक-दूसरे को देखा और project बंद कर दिया। उसने अपने सारे पत्ते खोल दिए थे, और पता चल गया कि वह कुछ खास नहीं है
      बाद में Steam पर इसी तरह के idea वाला game देखा। अगर उन्होंने independently सोचा था तो अच्छा, और अगर उन्होंने उस व्यक्ति से चुराया था तो भी अच्छा; अगर वे उस आदमी के नीचे अंत तक टिके रहे, तो वे पैसे के हकदार हैं
    • logic और programming की तरफ बेहद झुके व्यक्ति के रूप में, उल्टा मैं ऐसे व्यक्ति से मिलना चाहूंगा। लगता है मैं खुद idea-type इंसान नहीं हूं
      अगर idea सच में अच्छा और भरोसेमंद था, तो ईमानदारी से कहें तो यह काफी ठीक offer भी हो सकता था
    • sales, marketing, accounting और company चलाने के लिए बाकी सब संभालना 50%, शायद उससे भी ज्यादा value रखता है। हालांकि coding करने वाला व्यक्ति शायद काफी competent रहा होगा, लेकिन उसके company “चलाने” जितना competent होने की संभावना कम लगती है
    • अगर आपको सामने वाले की mental state बिल्कुल नहीं पता, तो नहीं जानता कि ऐसा कहना समझदारी है या नहीं
      अगर आपको लगता है कि किसी से “6 महीने बाद मैं तुम्हारा शानदार idea चुरा लूंगा” कहना ठीक है, तो आपको उम्मीद करनी चाहिए कि वह व्यक्ति problem पैदा करने वाला, या extreme case में नुकसान पहुंचाने वाला type न हो

  • काश कोई मेरी समस्या मेरी जगह हल कर देता। अभी मैं इस समस्या से इसलिए जूझ रहा हूँ क्योंकि ऐसा कोई समाधान नहीं है जिसे बस खरीदकर इस्तेमाल किया जा सके
    अगर कोई पसीना बहाकर मेरी समस्या हल कर दे, और on-call व maintenance तक अपने ऊपर ले ले, तो यह खुशी की बात होगी
    आखिर यह समस्या आपको खुद ही क्यों हल करनी है? आपका समाधान business ही क्यों होना चाहिए? business अपने और ग्राहकों के लिए value बनाने का काम है। अगर आप समस्या से ही चिपके हुए हैं, तो किसी और के बहुत मेहनत करके उसे हल करने के लिए आभारी होना चाहिए; और अगर आप ग्राहक पर केंद्रित थे, तो feedback पाने के लिए बहुत पहले ही कुछ न कुछ ग्राहकों के सामने रख देना चाहिए था

    • कुछ solo developers शायद नए ideas implement करना चाहते हैं, उन्हें कुछ हद तक सफल business बनाकर market पर मजबूत पकड़ बनाना चाहते हैं, फिर किसी बड़ी company को बेचकर बड़ी कमाई करना चाहते हैं
      लंबे समय तक company चलाना चाहने वाले लोग शायद बहुत ज़्यादा नहीं होंगे, लेकिन किसी दिलचस्प समस्या को हल करने या उससे निपटने के कारण अचानक बड़ी रकम मिलना ज़्यादातर लोगों को बुरा नहीं लगेगा
    • मूल लेखक: मेरे लिए यह महत्वपूर्ण इसलिए था क्योंकि जिस app को मैं कुछ समय से इस्तेमाल कर रहा था वह ठहर गया था और अब updates नहीं आ रहे थे। productivity के बारे में और सीखते हुए मैं उस app की सीमाओं तक पहुँच गया, और मुझे और features चाहिए थे
      मेरे app में डालने के लिए ideas लगातार आते रहे, लेकिन दूसरे developers शायद ऐसे ideas implement करने में दिलचस्पी नहीं रखते। मुझे control चाहिए था, इसलिए अंत में मैंने Benji launch किया: https://benji.so

  • मैं मूल लेखक हूँ। मुझे यह लेख update करना चाहिए। कुछ साल बाद, जब-जब यह लेख ऊपर आता था, HN पर आने वाली comments ने सच में मुझे motivate किया
    लोग हमेशा पूछते थे “बस app launch क्यों नहीं कर देते?”, इसलिए आखिरकार मैंने launch कर दिया
    इसे पूरा करके खुशी है, और मुझे लगता है कि यह इस category के किसी भी competing product से कहीं बेहतर है
    इसे https://benji.so पर देख सकते हैं। landing page अभी work in progress है

    • landing page browser को sluggish बना रहा है। कुछ images वाली start screen है, समझ नहीं आता यह कैसे संभव है। उस page पर आखिर चल क्या रहा है
    • मैंने भी इसी तरह launch न हो पाने वाला app development cycle झेला। React से शुरू किया, फिर React Native, Flutter पर गया, और आखिरकार GraphQL से SQLite पर भी shift किया
      मेरे app का भी मिलताजुलता goal था: habit motivation, goal compliance measurement, task scheduling और rescheduling को जोड़ना। मैंने इस पर कई साल काम किया, और इसे कभी bootstrap company बनाने का विचार मेरी identity से काफी जुड़ गया था
      project छोड़ने का decision कई चरणों में आया, लेकिन एक बड़ा अंतिम trigger यह था कि लंबे समय में मैं app developer बनकर नहीं जीना चाहता। छोड़ना मुश्किल था, लेकिन अब मैं उस decision से संतुष्ट हूँ। मूल लेख की तरह यह बाद में फिर जीवित हो सकता है—“कुछ भी पूरी तरह गायब नहीं होता”—लेकिन मुझे नहीं लगता कि मैं इसी specific project पर लौटूँगा
      ज़्यादातर productivity apps की “high cognitive load” समस्या से पार पाने के लिए core ideas में से एक life module marketplace था। उदाहरण के लिए कोई fitness influencer workout routine, diet और journal templates का bundle बेचता, और user उसे अपनी life में “install” करता
      बड़े language models churn detect करने और कारणों का अनुमान लगाने, या “न किए गए actions” पर respond करने को कहीं अधिक संभव बना देंगे। मुझे लगता है कि यह उन लोगों के लिए important है जो type-A personality वाले नहीं हैं और हर दिन लगातार productivity app इस्तेमाल नहीं करते
    • अभी आज़माया, और detected timezone name “Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris” दिखा
      GMT से difference सही है, लेकिन Brussels, Copenhagen, Madrid, Paris अफ्रीका में नहीं हैं, इसलिए यह बेहद confusing है। जो timezone data आप इस्तेमाल कर रहे हैं, उसे check करना बेहतर होगा
      नीचे की comment देखकर लगा कि यह issue नहीं था
    • सफेद background पर सफेद menu links दिखाई नहीं दे रहे। सोचा बता दूँ: https://i.imgur.com/Yd1hniV.png
    • अच्छा लग रहा है। शायद एक बार try करूँ। नाम इस दोस्त https://en.wikipedia.org/wiki/Benji से लिया है क्या? 6–8 साल की उम्र में मुझे यह बहुत पसंद था
      और “competitor” का नाम न बताने पर frustration और suspicion जताने के लिए माफ़ी। अब जब आपने अपना app launch कर दिया है, तो अगर वह competing product अभी भी है भी, तब भी उसका नाम बताने की संभावना शायद और कम हो गई होगी

  • जब आप अपने system के real user बनते हैं, तो perspective पूरी तरह बदल जाता है। मैं भी अपने लिए कुछ बना रहा था, और मुझे लगता था कि वह ready नहीं है और बिल्कुल usable नहीं है
    project छोड़ने के बाद मैंने उसे real user की तरह इस्तेमाल करने का फैसला किया, तो समझ आया कि users अनगिनत छोटी-छोटी समस्याओं के आदी होते हैं और अपने-आप workarounds ढूँढ लेते हैं। कुछ बनाने वाला अक्सर भूल जाता है कि कई कमियाँ disqualifying नहीं होतीं, और users बहुत ज़्यादा effort के बिना कई shortcomings से बचकर निकल जाते हैं। उस point पर perfectionism लगभग ego जैसा हो जाता है
    यह बात कुछ समय के लिए नजरअंदाज करना कि आप ही creator हैं, और कुछ समय तक fixes पर भी रोक लगाकर सच में इस्तेमाल करना—सब कुछ बदल सकता है

    • इसलिए मुझे लगता है कि “launch करो और तेजी से iterate करो” अक्सर सबसे अच्छा रास्ता है। किसी भी software project में critical bugs हो सकते हैं। अगर accounting package accounting ठीक से नहीं कर पाता, तो उसे launch नहीं करना चाहिए; लेकिन अगर कोई report किसी वजह से दो बार दिख रही है, तो users अगले iteration तक उसे संभाल सकते हैं। बस अगला iteration महीनों–सालों बाद नहीं होना चाहिए
      practically, real users के सामने release करने से पहले आप users को मिलने वाले ज़्यादातर “bugs” नहीं खोज पाएँगे। launch न करने पर आपको वे bugs fix करने का मौका भी नहीं मिलेगा जिनसे users सच में प्रभावित होते हैं
    • अभी इस्तेमाल किए गए app में built-in iOS web browser था जो ठीक से काम नहीं कर रहा था
      मैंने बस web page सीधे खोलकर इस्तेमाल किया, और username व password obviously iCloud से sync थे। Safari में user flow फिर से शुरू करने में 5 सेकंड और पूरा करने में सिर्फ 30 सेकंड लगे

  • “बस रिलीज़ कर दो” के उदाहरण के तौर पर यह सबसे अच्छा नहीं है। productivity apps, to-do, habit tracking, expense tracking, journaling, workout planning जैसी categories में कई लोग स्वतंत्र रूप से वही idea सोच लेते हैं
    जब मुझे खर्च रिकॉर्ड करने वाला app idea आया था, तब मुझे लगा था मैं कितना smart हूँ। फिर मैंने Play Store चेक किया। KRAZAM ने भी 5 साल पहले “The Hustle” वीडियो में इसी का मज़ाक उड़ाया था

    • यह शायद overbuilt app categories के इतिहास की सबसे overbuilt category हो सकती है
      इसका मतलब यह नहीं कि कोई नया variation सफल नहीं हो सकता। सफल चीज़ों में से ज़्यादातर पूरी तरह original नहीं होतीं। बस अगर आपको यह चिंता है कि कोई पहले अपना version निकालकर जीत जाएगा, तो एक बार आसपास देख लेना चाहिए
    • “Play Store चेक किया” वाला हिस्सा लगता है लेख की असली बात चूक गया। असली बात यह है कि competitors हों तब भी ship करो। बल्कि competitors idea को validate करने का अच्छा signal हैं, बुरा signal नहीं

  • व्यक्तिगत तौर पर मुझे “बहुत कोशिश करके मज़ेदार बनने” वाली writing style बर्दाश्त नहीं होती

    • सहमत। पढ़ना काफ़ी थकाऊ था। सही timing पर एक-दो sarcastic टिप्पणियाँ ठीक हैं, लेकिन ज़्यादा हो जाए तो नहीं
    • सिर्फ़ आप ही नहीं हैं; लोगों की पसंद अलग-अलग होना ठीक है

  • पढ़ते-पढ़ते छोड़ दिया। बहुत childish और cringe लगा
    आखिरकार उन्होंने सिर्फ़ proof of concept बनाया और उसी में संतुष्ट हो गए। अफ़सोस है, लेकिन यही जीवन है। उन्होंने काम किया और reward पाया
    सीखने वाली बात यह है कि ideas को own नहीं किया जा सकता

  • मैं इस बात से पूरी तरह सहमत हूँ। जब हमने Kviklet शुरू किया था, हम 3 लोग थे, और उनमें से एक बाकी दो की तुलना में कहीं ज़्यादा perfectionist था। सच कहूँ तो हमारे काफ़ी खराब पहले website version को डालने के लिए भी बहुत समझाना पड़ा, और repository public करना तो और मुश्किल था
    वह “co-founder” शुरुआत में ही चला गया, लेकिन अच्छा हुआ कि हमने जल्दी release करके बेचने की कोशिश की
    बात बनी नहीं और buyer भी नहीं मिला, लेकिन यह सोचकर ही डर लगता है कि हम अभी भी बिना यह जाने कि कोई पैसे देगा भी या नहीं, अंधेरे में सिर्फ़ उम्मीद पकड़े product बना रहे होते
    अब हमने backup plan के तौर पर इसे open source कर दिया है और कुछ काफ़ी अच्छे users भी मिल गए हैं। शायद इसे छोटी community भी कह सकते हैं: https://github.com/kviklet/kviklet
    यह वह startup success story नहीं है जिसकी एक साल पहले उम्मीद थी, लेकिन अब भी सिर्फ़ उम्मीदों पर टिके रहकर reality check के बिना रहने से यह कहीं बेहतर है। open source होने का मतलब यह भी नहीं कि support या premium version बेचकर थोड़ा पैसा नहीं कमाया जा सकता, है न। अभी यह बस एक मज़ेदार side project है

    • “database queries के लिए Pull Request जैसा review/approval flow” वाली description अच्छी नहीं है। queries को approval चाहिए—ऐसा अहसास नहीं होना चाहिए
      mutation, edit, update, modification जैसे शब्द इस्तेमाल करने चाहिए। query technically सही हो तो भी nuance में गलत और confusing लगता है

  • अगर मैं अपने लिए कुछ बना रहा हूँ, तो किसी और के पहले बना लेने से मुझे दुख नहीं होगा। वह तो बस इस बात का सबूत है कि idea अच्छा था
    बेशक मेरे दिमाग़ और कागज़ पर मौजूद कई personal projects, यहाँ तक कि वे भी जिन्हें सच में थोड़ा शुरू किया है, बेचने के लिए launch करने वाले नहीं हैं। वे ऐसी चीज़ें हैं जिन्हें मैं चाहता हूँ या जिन्हें दोस्त, परिवार, या दूसरे लोग उपयोगी समझ सकते हैं
    अगर alpha quality तक भी पहुँच जाएँ, तो शायद मैं उन्हें public कर दूँ ताकि कोई सोचे, “idea तो useful है, लेकिन implementation खास नहीं; मुझे इसे बेहतर बनाना चाहिए”

    • वास्तविकता में लगभग हर स्थिति में कोई न कोई पहले ही आपसे आगे निकल चुका होता है। अगर आप इतिहास में पहली बार कुछ automate कर रहे हों, तब भी मौजूदा manual process आपका शुरुआती competitor होता है। लेख वाला app भी सिर्फ़ दूसरे apps से नहीं, बल्कि उन तमाम partial solutions के combination से compete कर रहा है जिन्हें target customers पहले से इस्तेमाल कर रहे हैं
      और अगर आप first mover भी हैं, तो जल्द ही competitors आ जाएँगे और आपका advantage घटाएँगे; आगे बने रहने के लिए लगातार कोशिश करनी पड़ेगी
      इसलिए जब वैसे भी हमेशा कोई पहले से मौजूद है, और competition अभी या बाद में निश्चित है, तो किसी के पहले आ जाने की चिंता छोड़कर competitive advantage पर focus करना चाहिए। लगता है original author भी आखिरकार इसी realization तक पहुँचा, और उम्मीद है उनका अच्छा हो