3 साल बाद असफल हुए मेरे startup का code सार्वजनिक
(dylanhuang.com)- Konfig ने API integration को आसान बनाने वाले developer tools startup के रूप में शुरुआत की थी, लेकिन 3 साल बाद बंद होते समय उसने product code और operations artifacts वाली codebase को सार्वजनिक कर दिया
- मुख्य product SDK Generator था, जो OpenAPI specification से client libraries बनाता था, और बाद में documentation व interactive API testing environment तक विस्तारित हुआ
- कुछ startup customers से प्रतिक्रिया मिली, लेकिन contracts की कठिनाई और कम pricing के कारण इसे तेज-गति से बढ़ने वाला business बनाना मुश्किल था
- इसके बाद उसने vertical B2B SaaS AI product की ओर pivot किया, लेकिन कई interviews और sales processes के बावजूद बड़े business का भरोसा दिलाने वाला market response (traction) नहीं मिला
- सार्वजनिक repository बंद होने के समय की उसी स्थिति में है, और बिना cleanup या fixes के product code, pivot experiments, sales scripts, deployment settings और marketing website शामिल करती है
Konfig जो API developer tools बना रहा था
- Konfig 2022 के अंत में शुरू हुआ एक API developer tools startup था, जिसका focus developers के API के साथ काम करने के तरीके को सरल बनाना था
- लक्ष्य SDK generation, documentation और testing के आसपास के tools को बेहतर करना था
- इसका flagship product SDK Generator था
- यह OpenAPI specification को input के रूप में लेकर कई programming languages की client libraries generate करता था
- बाद में यह API documentation tool और interactive API testing environment तक फैल गया
Growth की सीमाएं और AI pivot
- कुछ startup customers के बीच traction था, लेकिन यह तेज-गति से बढ़ने वाले business में नहीं बदल पाया
- संभावित customers के साथ contracts बंद करना मुश्किल था, और साबित करने योग्य ROI होने के बावजूद pricing बहुत कम थी
- generative AI की प्रगति के बाद, उन्होंने माना कि पहले जिन समस्याओं को हल करना कठिन था उन्हें अब हल किया जा सकता है, और vertical B2B SaaS AI product की ओर pivot किया
- कई ideas पर user interviews और sales किए, लेकिन ऐसा traction नहीं मिला जिससे भरोसा हो कि दिशा एक बहुत बड़े business में बदल सकती है
बंद होने के समय जैसी थी वैसी ही सार्वजनिक की गई repository
- सार्वजनिक repository konfig-dev/konfig है
- repository को company बंद होने के समय की स्थिति में ही public किया गया
- कोई cleanup नहीं
- कोई polishing नहीं
- कोई fixes नहीं
- codebase एक वास्तविक startup code की unfiltered स्थिति दिखाती है
3 साल में बनाए गए प्रमुख products
- SDK Generator: OpenAPI-based SDK generator
- Markdown and OpenAPI Documentation: Markdown और OpenAPI-based documentation
- API Demos (Markdown Based Jupyter Notebooks): Markdown-based Jupyter Notebook format में API demos
- SDKs for Public APIs: public APIs के लिए SDKs का collection
साथ में सार्वजनिक किए गए operations code और experiments
- sales और marketing से जुड़ा code भी शामिल है
- Shell script for generating cold outbound message: cold outbound messages generate करने के लिए shell script
- Programmatic SEO Scripting: programmatic SEO script
- Marketing website: marketing website
- customer और sales से जुड़े artifacts भी बचे हुए हैं
- References to live customer deployments and pre-sales artifacts: live customer deployments और pre-sales artifacts के references
- Custom Notion Database Integration: Notion database का custom integration
- product operations और development tools भी देखे जा सकते हैं
- Product Documentation: product documentation
- Modified Changeset Bot: custom monorepo setup को support करने वाला modified Changeset Bot
- SDK Generator Integration Tests using Earthly: Earthly का उपयोग करके SDK Generator integration tests
- Python Code Formatting Service: Python code formatting service
- render.com deployment configuration:
render.yamldeployment configuration
- AI pivot और अन्य experiments भी repository में शामिल हैं
- AI Pivot Experimentation: AI pivot experiments
- API Documentation Generator Tool using LLMs/HTMX/Django: LLM, HTMX और Django का उपयोग करने वाला API documentation generator tool
- Python script for cropping blog post images: blog images crop करने के लिए Python script
founder की retrospective notes
- Dylan Huang ने मार्च 2022 में नौकरी छोड़ी और startup पर पूरा focus किया, और असफलता की संभावना जानते हुए भी challenge लिया
- वे इस failure को सफलता से अधिक सीख देने वाला अनुभव मानते हैं
- अगले कदम के रूप में वे नए अवसर तलाशने, hiring market में अपने लिए उपयुक्त role खोजने और लगातार सीखने व बढ़ने की योजना बना रहे हैं
- किसी दिन फिर से खुद कुछ बनाने की चुनौती के लिए भी वे खुले हैं
1 टिप्पणियां
Hacker News की राय
“हाइपर-ग्रोथ” वाले “बहुत बड़े बिज़नेस” के बजाय अगर लक्ष्य छोटा बिज़नेस होता, तो सोचता हूं कि अब तक कितने शानदार niche products बचे रह गए होते
विकसित देशों में 2–3 लोगों वाले startup को जीवित रहने के लिए 10 डॉलर प्रति महीने वाले license बहुत बड़ी संख्या में बेचने पड़ते हैं, और opportunity cost भी सोचनी पड़ती है
अगर शुरुआत से ही छोटा और sustainable बिज़नेस लक्ष्य बनाकर सफल हो जाएं, तो निवेश से बचा जा सकता है; लेकिन अगर कंपनी के मध्य/अंतिम चरण में बिल्कुल नई दिशा में pivot किया हो, तो संभव है कि cash reserves का ज़्यादातर हिस्सा पहले ही खर्च हो चुका हो
इस साल revenue 400,000 डॉलर, profit 150,000 डॉलर, growth rate 40% रहा, और sales outlook भी साल की शुरुआत की तुलना में काफी बेहतर हो गया है। अगले साल भी मजबूत growth की उम्मीद है, और market saturation से अभी काफी दूर हैं, इसलिए आने वाले कई सालों तक growth की गुंजाइश बड़ी है
salary और profit का 1/3 जोड़ें तो इस साल के हिसाब से 100,000 डॉलर होते हैं, और 40% growth पर कंपनी हर 2 साल में दोगुनी हो जाती है। अगर चीज़ें ठीक रहीं, तो salary और profit भर से ही स्थिति काफी अच्छी हो जाएगी, और इसके ऊपर founders को कई million डॉलर दिला सकने वाला acquisition opportunity भी जुड़ सकता है
Google जैसी कंपनी बनाने की कोशिश करना और Basecamp जैसी कंपनी बनाने की कोशिश करना, दोनों ठीक हैं; वे बस अलग तरह की कंपनियां हैं
बल्कि “low-risk business” बनाने के जोखिम को कम आंकना आसान है, और हर business मुश्किल होता है। Konfig को सलाम
Konfig का customer होने के नाते यह सचमुच अफसोसजनक है। शायद हम उनके पहले customer रहे होंगे, और लगता है शुरुआती commits में भी हमारा ज़िक्र था
Dylan और Anh-Tuan ने हमारे लिए कई वास्तविक समस्याएं बहुत शानदार तरीके से हल कीं। उन्होंने generated SDKs और अच्छी दिखने वाली hosted docs/tutorials एक ही जगह दिए, और हमारे API को call करके users को सीधे real data के साथ experiment करने दिया
Konfig से पहले हम API को wrap करने वाले SDKs हाथ से बेतरतीब तरीके से लिखते थे, और docs ReadMe पर host करते थे, लेकिन हमारे API की request signing requirements की वजह से वह interactively ठीक से काम नहीं करता था
Konfig ने इसे open source के रूप में जारी कर दिया, इसलिए अब हम docs को खुद host कर रहे हैं: https://docs.snaptrade.com/
मैं इस team का बहुत सम्मान करता हूं, और काश उन्हें किसी तरह जारी रखने का रास्ता मिल जाता
अगर आप Konfig जैसा product चला रहे हैं जिसे customers पसंद करते हैं, लेकिन revenue ज़रूरत के मुताबिक बड़ा नहीं हो रहा, तो price और बढ़ाने पर भी विचार किया जा सकता है। हम Konfig जितना charge करता था उसका 2–3 गुना भी देते, और बढ़ते हुए और भी देते, लेकिन उन्होंने मांगा ही नहीं; न ही SDK के हिसाब से monthly fee या demo के हिसाब से monthly fee जैसी usage-based billing बनाई
अमेरिकी startup culture सच में अजीब है। हर चीज़ को ultra-fast scale करने की ज़रूरत नहीं होती, और हर चीज़ का विशाल होना भी ज़रूरी नहीं है
बिज़नेस को sustainability पर ज़्यादा फोकस करना चाहिए, न कि 2–3 साल में तीन बार pivot करके फिर बंद हो जाने वाले तरीके पर
अगर आप कई European startup founders से कहें कि “5 साल बाद कंपनी 15–20 employees पर ठहर गई है, stable cash flow है, और founder खुद को सालाना 200k–250k dollars दे रहा है,” तो वे इसे बड़ी सफलता मानेंगे। अमेरिका में, खासकर अगर venture funding ली हो, तो इसे failure भी माना जा सकता है
मैंने एक Silicon Valley venture investor को साफ़-साफ़ कहते सुना है कि “अगर आप कंपनी को 50 million dollars में बेचने को success मानते हैं, तो आपका mindset गलत है और मैं आपके साथ काम नहीं करना चाहूँगा”
बड़े challenge और बड़े risk लिए बिना, छोटी success और stable growth से संतुष्ट रहेंगे तो बड़ा reward कभी नहीं मिलेगा। किसी व्यक्ति के लिए यह ज़्यादा healthy हो सकता है, लेकिन पूरी economy के लिए बुरा हो सकता है
यह culture “move fast and break things” वाली सोच को अपनाता है, यह दिलचस्प है, लेकिन लगता है कि यह मुख्यतः tech industry पर ही लागू होता है। कई बार fail हुए businessperson को “serial entrepreneur” कहा जाना भी ऐसा ही है; किसी unsustainable company को बेच देना success कहना मुश्किल है
सोचिए अगर कई sports में fail हुआ कोई व्यक्ति खुद को “serial athlete” कहे तो कैसा लगेगा—यह सोचकर हंसी आती है
venture funding न लें तो, जब तक आप consulting जैसे तरीकों से खुद funding न कर सकें, self-sustaining स्थिति तक पहुँचना कहीं ज़्यादा कठिन और लंबा हो जाता है। यहाँ model 37 Signals है, लेकिन वे Rails बनाने वाली company हैं, इसलिए बहुत exceptional हैं
और उस मुकाम पर पहुँच भी जाएँ, तो venture-funded competitor बेहतर network और पैसे के दम पर आकर आपको कुचल सकता है
large enterprises के लिए B2B sales cycle बेहिसाब लंबी है, और SMEs को जिस price point पर बेच सकते हैं वह पर्याप्त नहीं है
हम value देते हैं और customers का time बचाते हैं, फिर भी उस value को समझाना हमेशा कठिन होता है
दूर के ढोल सुहावने लगते हैं, लेकिन अगर B2B business में कई साल तक lights on रखने के लिए वही संघर्ष दोहराना पड़े, हर महीने अलग customers के साथ लगभग वही बातचीत करनी पड़े, और साल में 10 बार वही समझाना पड़े कि यह valuable क्यों है, तो समझ आता है कि लोग इसमें फँसना क्यों नहीं चाहते। burnout भी जल्दी आ सकता है
इसलिए यह भी समझ आता है कि लोग ऐसा business idea क्यों ढूँढना चाहते हैं जिसकी value साफ़ हो और लोग चिल्लाकर कहें, “पैसे ले लो”
पहला है return on investment। अगर आप दूसरे लोगों का पैसा लाते हैं तो वे स्वाभाविक रूप से return की उम्मीद करेंगे, और समझदार investor portfolio diversify करता है इसलिए जानता है कि बहुत-सी investments fail होंगी। इसलिए losses offset करने के लिए वह हर investment पर जितना हो सके उतना बड़ा grow करने का दबाव डालता है, ताकि कुछ बेहद high-performing companies failures की भरपाई कर दें
ऐसा vertical growth सिर्फ startups में नहीं, बड़ी companies में भी दिखता है। मेरे हिसाब से इसमें formalism, over-regulation और bureaucracy की बड़ी भूमिका है। अगर permits, taxes और payroll accounts setup जैसे अनगिनत procedures से गुजरना पड़ता है, और public listing के लिए और भी ज़्यादा steps लेने पड़ते हैं, तो नई company अलग से बनाने की तुलना में पहले से established company का scope बढ़ाना कहीं सस्ता और कम risky हो सकता है
लगता है मैं competitor था। मैं ReadMe.com का founder हूँ, और हम API docs और SDK वगैरह देते हैं
ठीक-ठीक नहीं जानता कि हम क्यों सफल हुए, लेकिन मैंने भी बहुत-से false starts देखे, और core idea को थोड़ा-थोड़ा iterate करते हुए तब तक सुधारा जब तक हम उस point तक नहीं पहुँचे जहाँ लोग साफ़ तौर पर excited दिखने लगे
मुझे पता था कि यह market कठिन है, इसलिए engineering के अलावा भी बहुत समय और effort लगाया, और खासकर जब हम ज़्यादा ईमानदारी से सामने आए, Hacker News हमेशा हमारे लिए supportive रहा
और सुनना चाहता हूँ, इसलिए privately संपर्क करने की कोशिश करूँगा
कुल मिलाकर, आपने जितना effort लगाया उसके लिए बधाई। company शुरू करना और खुद पर भरोसा रखना बेहद कठिन काम है, और आपको इस पर गर्व होना चाहिए
लगता है निकट भविष्य में यह outcome बहुत देखने को मिलेगा। AI bubble फूटने के साथ ऐसी चीज़ें दोहराई जाएँगी
“हमने सोचा कि generative AI को vertical B2B SaaS products में इस्तेमाल करके उन समस्याओं को हल किया जा सकता है जिन्हें पहले हल नहीं किया जा सका था। हमने कई ideas बनाए और pitch किए, लेकिन user response इतना positive नहीं था कि हमें भरोसा हो कि यह बड़ा business बनाने की सही direction है।”
मूल text जैसा है, उससे पहला impression यह बनता है कि “यह लिखने वाला व्यक्ति एक temporary और संकीर्ण trend culture में गहराई से धँसा हुआ है, इसलिए सहज रूप से चिढ़ पैदा होती है, और पूरी तरह fail होने के तुरंत बाद भी मानसिक रूप से उससे बाहर नहीं निकल पाया है”
यह पहली कहानी नहीं है जहाँ एक product जो ठीक fit नहीं हो रहा था, pivot direction ढूँढते-ढूँढते AI को जवाब मान बैठा और fail हो गया
पहले भी कहा है, लेकिन दोहराने लायक है। जब हम समझेंगे कि AI किन चीज़ों में अच्छा है और किनमें नहीं, तब हम AI को goal नहीं बल्कि tool की तरह treat करना शुरू करेंगे, और product ideas सोचना भी stable हो जाएगा
इसलिए मुझे नहीं लगता कि यहाँ समस्या product-market fit थी
इसे कैसे देखा जाए, यह मुझे ठीक से समझ नहीं आ रहा। एक तरफ, आत्मचिंतन, असहज सच का सामना करने और काफ़ी व्यापक toolset बनाने के लिए सराहना बनती है
लेकिन अंदर देखें तो यह tools के ऊपर लिपटा हुआ tool है। API classification tool लगता है कि भारी काम का बड़ा हिस्सा OpenAI को सौंप देता है
“आप दुनिया के सर्वश्रेष्ठ स्तर के classifier हैं। इन APIs को इन groups में से किसी एक में फिट करें।”
बाकी files wiring code हैं और model-view-controller की boundaries थोड़ी धुंधली हैं। Tests भी दिखे, और मुझे लगा कि जिन tools को wrap किया जा रहा है उनमें बाहरी नियंत्रण से बाहर बदलाव बहुत होंगे, इसलिए यह महत्वपूर्ण होगा। लेकिन असल में वे IntelliJ के default
contextLoads()functional test जैसे थे—बस यह जांचने के स्तर पर कि dependencies हैं और compilation fail नहीं हो रहाVision है और यह Pareto principle से भी मेल खाता है, लेकिन ऐसा लगा कि वे यह hypothesis validate कर रहे थे कि market अपनी चीज़ों को maintain करने में रुचि नहीं रखता, जबकि internally वे अपनी maintenance problem भी हल नहीं कर पाए
अगर वे पहले खुद अपने लिए वह कारण हल कर पाते, तो शायद दूसरों के लिए भी हल कर पाते। लेकिन ऐसा करने के लिए कोई सचमुच इस्तेमाल होने वाला product चाहिए, ताकि दर्द महसूस हो और end users के प्रति empathy बने—यह एक dilemma जैसा दिखता है
Failed startup शर्म की बात नहीं है। हम में से ज़्यादातर लोगों में तो कोशिश करने की हिम्मत भी नहीं होती
Code में बहुत ज़्यादा interest की उम्मीद करना मुश्किल है। Business और लोगों के बिना किसी company के code की value, अगर कोई खास technical secret weapon न हो, तो काफ़ी negative होती है
भले ही technically कोई शानदार हिस्सा हो, लोग शायद बस यह समझना चाहेंगे कि वह हिस्सा कैसे काम करता है; code खुद इस्तेमाल करने की संभावना कम है
हालांकि एक customer ने Konfig के बंद होने के असर से निपटने का तरीका ढूंढते समय हमारे documentation platform को self-deploy करने में सफलता पाई
अगर आपके पास जल्दी revenue लाने वाला business plan या भारी funding नहीं है, तो tech startup नहीं बनाना चाहिए। आमतौर पर business कहां जाएगा, इसकी कम-से-कम समझ भी न हो तो funding पाना मुश्किल होता है, और technologists अक्सर business side को पर्याप्त नहीं समझते
ज़्यादातर companies startup नहीं होतीं, वे बस companies होती हैं। वे revenue कमाती हैं और bills भरती हैं। Startup वह company है जो revenue के बिना उधार के समय और पैसे पर जीती है; और खासकर अगर वह पैसा आपका अपना है, तो plan चाहिए
Venture-funded companies में से ज़्यादातर fail होती हैं। Venture capital का काम उन companies को जल्दी fail कराना है जो fail होने वाली हैं, और उन चंद companies से अपना business चलाना है जो fail नहीं होतीं और explosively सफल होती हैं। “Accelerating” या “fundraising” का मतलब यह नहीं कि आप success path पर हैं; इसका मतलब है कि आप ऐसी जगह पर चढ़ गए हैं जहां आपको odds को हराना है और आपके पास ज़्यादा समय नहीं बचा
अगर company सफल है और revenue है, तो उसे venture capital की ज़रूरत नहीं होती। ऐसे में पूछना चाहिए कि आप उनसे बात क्यों कर रहे हैं। अगर revenue बनाना मुश्किल है, तो venture capital उसे ठीक नहीं कर सकता
कई venture capitalists आलसी होते हैं और सफलता मिलने के बाद ही रुचि दिखाते हैं। इसलिए एक अजीब dynamic बनता है: शुरुआती दौर में funding पाने वाली companies fail हो जाती हैं, और जिन companies को funding नहीं मिलती वे सफल होती हैं
मेरी मौजूदा company 4 साल से पूरी तरह bootstrapped चल रही है। हम revenue के लिए संघर्ष कर रहे हैं, जितना समय मिल सकता है उसमें काम फिट कर रहे हैं, और मैं ज़्यादातर side consulting से जीवनयापन करता हूँ। Company ने लगातार 3 साल अपना सबसे सफल साल देखा है, और अब हम उस मुकाम के करीब हैं जहाँ मैं consulting छोड़कर business पर focus कर सकूँ, लेकिन यह लंबा सफर रहा है
Open source के बारे में: जो चीज़ें business-specific code या core intellectual property नहीं हैं, उन्हें मैं public कर देता हूँ। एक बड़ा कारण यह भी है कि अगली company शुरू करते समय वही boring काम फिर से नहीं बनाना चाहता। मैंने देखा है कि ये चीज़ें speed धीमी कर देती हैं
Startups में बहुत लोग intellectual property को लेकर obsessed रहते हैं, लेकिन हकीकत में ज़्यादातर software इतना valuable नहीं होता। फिर भी उसे बनाने में समय, पैसा और ऊर्जा लगती है
इसलिए मैं बहुत से tools और frameworks public करता हूँ, जिनका main user मैं ही रहूँगा। ताकि उन्हें अगले projects में भी इस्तेमाल कर सकूँ
Code dump अपने-आप में दिलचस्प हो सकता है, लेकिन लगता है कि इसमें license नहीं लगा है। ठीक से open source license लगा दिया जाए तो यह कहीं ज़्यादा useful होगा
Developer tools market सचमुच कठिन है
लगभग हर architecture decision यह बन जाता है कि “इस problem को solve करने के लिए कौन-सा open source tool इस्तेमाल कर सकते हैं”
कोई पैसे नहीं देना चाहता, और यह ठीक है
इसलिए दूसरे areas में भारी जरूरत होने के बावजूद developer tools startups बनाने वाली companies बहुत हो जाती हैं
अगर कुछ शुरू करना चाहने वाले experienced developers के पास ऐसे लोगों को ढूंढने का कोई तरीका हो—सिर्फ संयोग और networking से अलग—जिनके पास problem, domain expertise और founder बनने की इच्छा हो, तो बहुत value unlock हो सकती है
इसलिए ज़्यादातर commercial tools की usefulness के लिहाज से lifespan limited होती है, और वे आमतौर पर nice-to-have ही रह जाते हैं
साथ ही बहुत से developers employed होते हैं और उनके पास personal tools budget नहीं होता। Market असल में freelance developers या developers को hire करने वाले managers तक सिमट जाता है
Team managers इस तरह के खर्च को बारीकी से देखते हैं और आमतौर पर budget भी ज़्यादा नहीं होता। ज़्यादातर companies में developers के लिए personal tools budget जैसी कोई चीज़ नहीं होती
Freelancers भी आमतौर पर वही tools इस्तेमाल करते हैं जो उन्हें pay करने वाली company इस्तेमाल करती है, और वे ज़्यादातर free tools होते हैं। Paid tools में contractor licenses की भी चिंता करनी पड़ती है, जिससे freelancers को use करना और complex हो जाता है। इसलिए चीज़ों को simple रखने के लिए वे ऐसे tools से बचने की प्रवृत्ति रखते हैं
आपको यह भी पता होता है कि developers कहाँ इकट्ठा होते हैं और क्या चीज़ें उनके साथ काम करती हैं, तो सब ठीक दिखता है
लेकिन जैसा कहा गया, बहुत से developers पैसे नहीं देना चाहते, और वे ऐसा open source solution ढूंढ लेते हैं जो थोड़ा कम convenient हो, लेकिन जरूरी काम कर दे। ऊपर से सामने वाले लोग वे हैं जिनका पेशा और जीवन software बनाना है, इसलिए जवाब “मैं खुद ही बना लेता हूँ” भी हो सकता है
क्या कई services को एक bill में bundle करने वाला कोई business नहीं है? या फिर अभी भी AWS, Azure, GCloud ही इस्तेमाल करने पड़ेंगे?