KISS या मरो: वरिष्ठ इंजीनियर स्टार्टअप्स में क्यों विफल होते हैं

मेरा पहला स्टार्टअप एक असफलता था, और कई पड़ोसी स्टार्टअप भी असफल हुए। हमारे पास था: GCP क्रेडिट में $100K, एक संस्थापक इंजीनियर जिसने एंटरप्राइज में सिस्टम बनाए थे, और गो-टू-मार्केट। और हम असफल हुए, इसलिए नहीं कि हमने इसे गलत बनाया, बल्कि इसलिए कि हमने इसे अच्छी तरह से बनाया। यही समस्या थी।

जबकि हम एक "अन-ऑप्टिमल" टेक स्टैक के साथ जूझने में समय बिता रहे थे, हमने सबसे महत्वपूर्ण चीज खो दी: समय, गति, और रणनीतिक रूप से एक अवसर।

यह कहानी सामान्य ज्ञान के बिना लोगों के बारे में नहीं है। मेरे पास सामान्य ज्ञान था, और हम जानते थे कि हमें चीजों को सरल रखना चाहिए। लेकिन जब आपका मानसिक मॉडल स्थिति के अनुरूप नहीं होता है, तो आपका सारा सामान्य ज्ञान बह जाता है। आप "सही" निर्णय लेते हैं जो आपको मार देते हैं।

यह खराब इंजीनियरिंग की कहानी भी नहीं है। यह इस बारे में है कि कैसे अच्छी इंजीनियरिंग स्टार्टअप को मारती है। कैसे वह अनुभव जो आपको वरिष्ठ बनाता है, आपकी सबसे बड़ी देनदारी बन जाता है। कैसे "इसे सही करना" या यहां तक कि "इसे सरल करना" अक्सर गलत करना होता है।

यह लेख मानसिक मॉडल प्रस्तुत करता है जो आपको सही निर्णय लेने और मेरे द्वारा किए गए गलत निर्णयों से बचने में मदद करेंगे।

:::tip यह किसके लिए है: शुरुआती चरण के स्टार्टअप शुरू करने या उनमें शामिल होने वाले वरिष्ठ इंजीनियर। अगर आपने एंटरप्राइज या बिग टेक में 5+ साल बिताए हैं, तो यह आपकी चेतावनी है।

:::

\

मानसिक मॉडल #1 - "मुफ्त" इंफ्रास्ट्रक्चर सबसे महंगा है

GCP क्रेडिट में $100K एक उपहार की तरह लगता है, लेकिन यह एक जाल है। यह आपको ओवर-इंजीनियरिंग की ओर धकेलता है क्योंकि "यह पहले से ही भुगतान किया गया है।" आपको कंप्यूट इंस्टेंस, लोड बैलेंसर, कंटेनर रजिस्ट्री और एंटरप्राइज टूल मिलते हैं जिन्हें एंटरप्राइज सेटअप की आवश्यकता होती है। आपको क्या प्राप्त करने की आवश्यकता है? एक "पुश टू डिप्लॉय" बटन।

निश्चित रूप से, आप GCP/AWS/Azure पर "GitHub से VM पर डिप्लॉय" वर्कफ़्लो बना सकते हैं। कुछ उत्पाद करीब आते हैं। लेकिन इसके लिए अतिरिक्त कदम उठाने की आवश्यकता होती है: क्लाउड बिल्ड कॉन्फ़िगर करना, IAM भूमिकाएँ सेट करना, डिप्लॉयमेंट स्क्रिप्ट लिखना, सीक्रेट्स प्रबंधित करना और हेल्थ चेक कॉन्फ़िगर करना। वास्तविक उत्पादों को डिप्लॉय करने से पहले आप डिप्लॉयमेंट इंफ्रास्ट्रक्चर बनाने में समय बर्बाद करते हैं।

इस बीच, Railway या Fly.io जैसे प्लेटफॉर्म आपको वह देते हैं जिसकी स्टार्टअप को वास्तव में आवश्यकता होती है: GitHub से स्टार्ट-एंड-गो डिप्लॉयमेंट के साथ एक स्थायी VM। जितना आसान हो सकता है: आप अपना कोड पुश करते हैं, और यह डिप्लॉय हो जाता है। बस उपयोग के लिए तैयार VM जिसमें एनवायरनमेंट वेरिएबल्स, SSL, लोड बैलेंसर, लॉग आदि हैं। यह "मुफ्त" नहीं है, लेकिन यह तैयार है।

फ्री क्रेडिट आपको ओवर-इंजीनियरिंग की ओर धकेलते हैं क्योंकि "यह पहले से ही भुगतान किया गया है।" आप खुद को यह विश्वास दिलाते हैं कि आप पैसे बचा रहे हैं जबकि आप अपने सबसे मूल्यवान संसाधन को खर्च कर रहे हैं: समय।

\

मानसिक मॉडल #2 - "न्यूनतम" <> "सरल"

पारंपरिक KISS सिद्धांत हमें अपने सॉफ्टवेयर को सरल रखने के लिए कहता है। लेकिन स्टार्टअप में, यह गलत लक्ष्य है। आपको अपने सॉफ्टवेयर को सरल नहीं रखना चाहिए; आपको अपने समाधान को सरल रखना चाहिए।

वास्तविक सरलता को कोड जटिलता नहीं, बल्कि कुल प्रयास से मापा जाना चाहिए:

कुल प्रयास = प्रारंभिक निर्माण + रखरखाव + डीबगिंग + फीचर जोड़ना + सुरक्षा अपडेट + स्केलिंग परिवर्तन

जब आप शुरू से बनाते हैं, तो आप हमेशा के लिए इन सभी के मालिक होते हैं। जब आप एक सेवा का उपयोग करते हैं, तो इनमें से अधिकांश शून्य हो जाते हैं। "भारी" थर्ड-पार्टी सेवा वास्तव में सरल समाधान है क्योंकि यह कुल प्रयास को कम करती है।

मेरा OAuth उदाहरण

हमारे संस्थापक इंजीनियर ने एक "अज्ञात लाइब्रेरी" का उपयोग करने के बजाय OAuth को शुरू से बनाने का फैसला किया। एक सप्ताह बाद, उन्होंने एक PR सबमिट किया: JWT टोकन, रिफ्रेश टोकन रोटेशन, सेशन मैनेजमेंट और रोल-आधारित एक्सेस कंट्रोल के साथ क्लीन OAuth इम्प्लीमेंटेशन। कोई निर्भरता नहीं, कोई वेंडर लॉक-इन नहीं, बस कोड जिसे हम नियंत्रित करते थे।

मैंने PR को अस्वीकार नहीं किया। और यह एक गलती थी। एक सप्ताह के काम को फेंकना मनोबल को कुचल देगा। लेकिन यह कोड जटिलता पैदा करता है और इसे गलत पटरियों पर डाल देता है। इसके अलावा, पहले से दृष्टिकोण पर चर्चा न करना हमारी वास्तविक गलती थी। हमने इंजीनियरिंग गर्व को एक रणनीतिक निर्णय लेने दिया।

फिर, एक क्लाइंट को Microsoft OAuth और Google OAuth की आवश्यकता थी। कस्टम इम्प्लीमेंटेशन का मतलब था रिफैक्टरिंग, रिफ्रेश टोकन रोटेशन, एज केस, RBA और अन्य चीजों के दिन। प्रत्येक "सरल" जोड़ के लिए हमारे कस्टम ऑथ की गहरी समझ की आवश्यकता थी। हर सुरक्षा अपडेट हमें लागू करना था। हर नई आवश्यकता हमें कोड करनी थी।

सिद्धांत

क्लासिक सीनियर इंजीनियर की गलती: परिणामों के बजाय नियंत्रण के लिए अनुकूलन। स्टार्टअप में, वास्तविकता के लिए सीनियर इंजीनियरों के सोचने के तरीके को पूरी तरह से उलटने की आवश्यकता होती है:

1. सोचना बंद करें: "यह सिर्फ कुछ दिनों की कोडिंग है" \n सोचना शुरू करें: "यह कुछ दिन है जब मैं अपने वास्तविक उत्पाद को कोड नहीं कर रहा हूं"
2. सोचना बंद करें: "मैं इसे आसानी से बना सकता हूं" \n सोचना शुरू करें: "मैं इसे न बनाकर आसानी से हल कर सकता हूं"
3. सोचना बंद करें: "थर्ड-पार्टी सेवाएं जटिलता जोड़ती हैं" \n सोचना शुरू करें: "थर्ड-पार्टी सेवाएं जटिलता को अवशोषित करती हैं"

\

\

मानसिक मॉडल #3 - आराम विकल्प

हमने Angular चुना क्योंकि हमारे संस्थापक इंजीनियर इसे गहराई से जानते थे। स्मार्ट निर्णय, है ना? अपनी ताकत का उपयोग करें, गुणवत्ता वाला कोड शिप करें। फ्रेमवर्क ठीक था, लेकिन समस्या इसके इकोसिस्टम की थी।

इकोसिस्टम ट्रैप

Angular उत्कृष्ट है और हमारा इंजीनियर इससे कुछ भी बना सकता था।

लेकिन "कुछ भी" शुरू करने में समय लगता था। डिप्लॉयमेंट, प्रमाणीकरण और बुनियादी UI कंपोनेंट्स को सेट करने का मतलब था एक भी फीचर लिखने से पहले अंतहीन कॉन्फिगरेशन। जबकि हम Angular Material थीम को डीबग कर रहे थे, प्रतिस्पर्धी Next.js + Vercel का उपयोग कर सकते हैं (और करेंगे) और पहले से ही उपयोगकर्ताओं को ऑनबोर्ड कर रहे थे।

बस Next.js + Vercel पथ से तुलना करें: पहले दिन npx create-next-app के साथ एक स्केलेटन ऐप डिप्लॉय करें, Clerk प्रमाणीकरण और shadcn/ui कंपोनेंट्स जोड़ें, पहले दिन वास्तविक फीचर्स शिप करें। एक ही गंतव्य, पूरी तरह से अलग यात्रा।

ऐसा क्यों होता है?

अंतर फ्रेमवर्क की गुणवत्ता नहीं है, यह इकोसिस्टम अनुकूलन है। Next.js/React अन्य स्टार्टअप के लिए टूल बनाने वाले वेंचर-बैक्ड स्टार्टअप से घिरा हुआ है:

• UI: shadcn/ui - कॉपी, पेस्ट, शिप
• Auth: Clerk/Supabase - मिनटों में कॉन्फिगर करें
• Deploy: Vercel - git push का मतलब प्रोडक्शन
• बाकी सब कुछ: अगर स्टार्टअप को इसकी जरूरत है, तो किसी ने एक सेवा बनाई है

Angular का इकोसिस्टम एंटरप्राइज की सेवा करता है: शक्तिशाली, लचीला, अनंत रूप से अनुकूलन योग्य। 50 की टीमों के लिए परफेक्ट(?) और 3 की टीमों के लिए जहर।

\

मानसिक मॉडल #4 - कोर बनाएं, कॉन्टेक्स्ट किराए पर लें

लेकिन सही उपकरणों के साथ भी, एक अंतिम जाल है: चीजों को बनाने की बाध्यता क्योंकि आप कर सकते हैं, न कि क्योंकि आपको करना चाहिए। यह जाल तकनीकी रूप से मजबूत टीमों और हमारी कल्पना से अधिक स्टार्टअप को मारता है: ऐसी चीजें बनाना जिन्हें किसी ने नहीं मांगा क्योंकि आप कर सकते हैं, न कि क्योंकि आपको करना चाहिए।

हमने कुल मिलाकर कम से कम एक महीना ऐसी सुविधाओं पर बिताया जिनकी किसी को जरूरत नहीं थी। कस्टम OAuth जब Auth0 मौजूद था। एक Postgres-आधारित जॉब क्यू जब Redis + Celery मौजूद था। पहले दिन से Terraform, जब कंसोल ठीक काम कर रहा था। प्रत्येक निर्णय उत्पादक लगता था, लेकिन प्रत्येक ग्राहकों से बात करने या अन्य ग्राहक विकास करने जैसी वास्तविक चुनौतियों का सामना करने के लिए आत्म-विनाश था।

पैटर्न सरल है: अगर ग्राहक इसके लिए आपको नहीं चुनेंगे, तो इसे मत बनाइए।

मेरा $50 नियम

यदि एक SaaS की लागत $50/माह से कम है, तो आप इसे बनाने का खर्च नहीं उठा सकते। आपका समय बहुत महंगा है।

कस्टम OAuth बनाने में कुल रखरखाव और विभिन्न OAuth प्रदाताओं को जोड़ने में 1-2 सप्ताह लगते हैं। स्टार्टअप बर्न रेट पर, यह इंजीनियरिंग समय में $5,000-$15,000 है, या अवसर समय खोने में। Auth0 25,000 सक्रिय उपयोगकर्ताओं तक मुफ्त है, फिर $35/माह। आप इसे एक बार बनाने की लागत से 35 वर्षों तक Auth0 के लिए भुगतान कर सकते हैं।

तो, यह पैसे के बारे में नहीं है बल्कि प्राथमिकताओं और अवसर लागत के बारे में है।

अपवाद

मेरी राय में, केवल तभी बनाएं जब आप इसके बिना उपयोगकर्ताओं के बारे में नहीं सीख सकते।  एक सरल उदाहरण है जब आपको यह परीक्षण करने की आवश्यकता होती है कि क्या उपयोगकर्ता AI-जनित रिपोर्ट के लिए भुगतान करेंगे। सबसे सरल संस्करण बनाएं जो मांग साबित करता है। और बाकी सब कुछ फिसलने की कोशिश करता है। हां, इंफ्रास्ट्रक्चर को छोड़ दें, "इसे सही करना" छोड़ दें, ऐसे बेस्ट प्रैक्टिस छोड़ दें जो फीचर्स शिप नहीं करते, टेस्ट छोड़ दें। फिर से, कोड लिखने में जितना हो सके उतना आलसी बनें।

मैं वास्तव में क्या उपयोग करता हूं

• Auth: Clerk (React-native, बेहतर DX) या Auth0 (B2B-फोकस्ड, एंटरप्राइज-रेडी)
• Email: Resend (डेवलपर-फर्स्ट) या SendGrid (बैटल-टेस्टेड)
• Analytics: PostHog (स्केल तक मुफ्त)
• Monitoring: Sentry (त्रुटियों के लिए अजेय)
• Hosting: Cloudflare या Vercel (यदि Next.js पर पूरी तरह से)

ये समर्थन नहीं हैं बल्कि गति के लिए अनुकूलित मेरे अपने विकल्प हैं। मुझे लगता है कि आपका स्टैक अलग होगा लेकिन यह सिद्धांत नहीं होगा।

\

\

निचोड़

LLM ने बिल्डिंग को कमोडिटाइज़ कर दिया है। Claude के साथ कोई भी जूनियर उस कस्टम ऑथ सिस्टम को बना सकता है जिस पर आपको इतना गर्व है। आपका मूल्य अब इसमें नहीं है कि आप क्या बना सकते हैं, बल्कि यह जानने में है कि क्या नहीं बनाना है।

नेतृत्व संकेतों को शोर से अलग करने की क्षमता है। वास्तविक वरिष्ठता का अर्थ है अपने ज्ञान के 90% को अनदेखा करने का अनुशासन रखना और आज के समाधान को शिप करना, न कि कल के आर्किटेक्चर को।