𝗦𝗵𝗶𝗽𝗽𝗶𝗻𝗴 𝟰 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝘀 𝗦𝗼𝗹𝗼
मैंने एक साल में चार प्रोडक्ट्स शिप किए।
इनमें spectr-ai, Scry, Argus, और Lomi शामिल हैं। ये सुरक्षा (security), Web3, ब्राउज़र एक्सटेंशन और B2B SaaS को कवर करते हैं।
इन्हें अकेले बनाने से मुझे वे सबक मिले जो कोई भी अकेला प्रोजेक्ट नहीं सिखा सकता था।
यहाँ वह सब है जो मैंने सीखा।
- उबाऊ (boring) हिस्सों के लिए बजट रखें।
मैंने अपनी ऊर्जा कठिन तकनीकी समस्याओं पर खर्च की। मैंने AI विश्लेषण और bytecode reconstruction पर ध्यान केंद्रित किया। ये हिस्से कठिन थे लेकिन अनुमानित (predictable) थे।
असली खतरे गैर-आकर्षक (unglamorous) कार्य थे। Chrome Web Store रिव्यूज, proxy resolution और deployment सेटअप ने लगभग मेरे प्रोजेक्ट्स को डुबो ही दिया था।
असली काम अक्सर किनारों (edges) पर एकीकरण (integration) करना होता है। मैंने हर बार इसके लिए कम समय/संसाधन का अनुमान लगाया।
- AI शुरुआत को सस्ता बनाता है, अंत को नहीं।
लोग कहते हैं कि AI एक व्यक्ति को कंपनी बनाने की अनुमति देता है। सच्चाई इससे कहीं अधिक विशिष्ट है।
AI किसी फीचर के पहले 80% हिस्से को संभाल लेता है। यह boilerplate बनाता है और टेस्ट का ड्राफ्ट तैयार करता है। इससे अकेले काम करना संभव हो जाता है।
AI आखिरी 20% को नहीं संभालता। इसमें edge cases, सुरक्षा समीक्षा (security reviews) और अस्थिर कनेक्शनों (flaky connections) की डिबगिंग शामिल है। वह हिस्सा अभी भी धीमा है। इसके लिए अभी भी आपके पूर्ण ध्यान की आवश्यकता होती है।
- नाम बदलना प्रगति है।
जैसे-जैसे वे बढ़े, मैंने कई प्रोजेक्ट्स का नाम बदल दिया। मुझे पहले लगता था कि नाम बदलने का मतलब है कि मैंने अपनी मेहनत बर्बाद कर दी।
मैं गलत था। नाम बदलने का मतलब है कि आप अंततः उत्पाद (product) को समझ गए हैं। कोड वही रहता है, लेकिन आपकी स्पष्टता (clarity) में सुधार होता है।
- पॉलिश से पहले लॉजिक आता है।
एक सुंदर UI एक जाल है। यदि कार्यक्षमता (functionality) बदलती है, तो आपको डिज़ाइन को फिर से बनाना होगा। इससे समय बर्बाद होता है।
मेरा नियम सरल है: किसी भी स्टाइलिंग से पहले लॉजिक और टेस्ट पूरे करें। एक फीचर तभी काम करता है जब कोई टेस्ट उसे साबित कर दे। जब तक वह काम न करने लगे, उसे सुंदर न बनाएं।
- असफलताओं के बारे में लिखें।
'Building in public' का मतलब खराब हिस्सों को भी साझा करना है।
मैंने हैक्स, विफल दृष्टिकोणों और बग्स के बारे में लिखा। इसने मुझे चुपचाप काम करने की तुलना में बहुत कुछ सिखाया। इसने एक ऐसा दर्शक वर्ग (audience) भी बनाया जो आपकी प्रक्रिया (process) की परवाह करता है।
यदि आप अकेले निर्माण करते हैं, तो इन नियमों का पालन करें:
• कोर फीचर की तुलना में इंटीग्रेशन पर अधिक समय बिताएं। • थकाऊ काम (grunt work) के लिए AI का उपयोग करें, लेकिन कठिन 20% खुद करें। • UI के बजाय टेस्ट को प्राथमिकता दें। • काम करते समय अपनी गलतियों को साझा करें।
शिपिंग एक क्रिया (verb) है। यह कोई पूर्ण स्थिति (finished state) नहीं है। इसे चार बार करने से मुझे एक उत्पाद को पूर्ण बनाने की तुलना में कहीं अधिक सीखने को मिला।
Optional learning community: https://t.me/GyaanSetuAi