एक वीकेंड में MVP कैसे बनाएं: एक यथार्थवादी योजना
एक वीकेंड में MVP बनाने के लिए अपने विचार को एक तरह के उपयोगकर्ता के लिए एक काम तक सीमित करें, शुक्रवार की शाम उसे लिख लें, शनिवार को AI ऐप बिल्डर से मुख्य लूप बनाएँ, और रविवार को ज़रूरी बातों पर (डेटा सेव करना, लैंडिंग पेज, प्रकाशन) काम करें, फिर असली लोगों को दिखाएँ। हर वह चीज़ छोड़ें जो उस एक सवाल का जवाब देने में मदद न करे जिसके लिए MVP बना है। एक वीकेंड एक खुरदुरा, काम करने वाला संस्करण बनाने के लिए काफ़ी है। यह एक तैयार उत्पाद के लिए काफ़ी नहीं है, और यह ठीक है।
वीकेंड MVP क्या है (और क्या नहीं)
MVP (न्यूनतम व्यवहार्य उत्पाद) वह सबसे छोटी चीज़ है जो आप यह सीखने के लिए बना सकते हैं कि विचार काम करता है या नहीं। MVP क्या है इस विचार को पूरी तरह समझाता है। वीकेंड के लिए इसका मतलब है:
- एक उपयोगकर्ता प्रकार। “फ़्रीलांसर और एजेंसियाँ और उनके क्लाइंट” नहीं।
- एक काम, शुरू से अंत तक। उपयोगकर्ता शुरू कर सके, पूरा कर सके, और नतीजा पा सके।
- असली, नकली नहीं। वह डेटा सेव करता है, फ़ोन पर काम करता है, और एक असली पते पर रहता है।
- खुरदुरे किनारों की छूट। सादा डिज़ाइन, कम सेटिंग्स, और पर्दे के पीछे कुछ काम हाथ से।
यह किसी छोटे पूरे उत्पाद का नाम नहीं है। यह उस एक हिस्से का नाम है जो आपकी सबसे बड़ी धारणा को परखता है।
वीकेंड से पहले: सवाल चुनें
हर MVP एक सवाल का जवाब देता है। उसे लिख लें, क्योंकि वही तय करता है कि क्या बनाना है:
| सवाल | MVP को क्या चाहिए |
|---|---|
| “क्या लोग इसे इस्तेमाल करेंगे भी?” | मुख्य फ़ीचर, मुफ़्त, और यह देखने का तरीका कि कौन लौटता है |
| “क्या वे इसके लिए पैसे देंगे?” | मुख्य फ़ीचर और भुगतान का तरीका, चाहे सिर्फ़ एक भुगतान लिंक |
| “क्या मैं नतीजा दे सकता हूँ?” | सरल फ़्रंट एंड, और पीछे आप कुछ काम हाथ से करें |
| “क्या बनाने से पहले माँग है?” | शायद अभी कोई उत्पाद नहीं: पहले एक वेटलिस्ट पेज |
आदर्श रूप से आपने ऐसे कुछ लोगों से बात की हो जिनकी यह समस्या है। नहीं की, तो ऐप विचार कैसे परखें बताता है कि कैसे करें, और शुक्रवार से पहले दो-चार बातचीत पूरे वीकेंड को ज़्यादा उपयोगी बना देती है।
योजना
शुक्रवार की शाम: तय करें (2 से 3 घंटे)
- एक वाक्य लिखें: “[उत्पाद] [खास उपयोगकर्ता] को [एक काम] करने में मदद करता है, [मौजूदा दर्द] के बिना।”
- मुख्य लूप के कदम सूचीबद्ध करें, जैसे: साइन अप, नौकरी का विवरण चिपकाएँ, टेलर्ड कवर लेटर पाएँ, संपादित करें, कॉपी करें।
- डेटा की सूची बनाएँ: क्या सेव होगा, और उसका मालिक कौन है।
- “इस वीकेंड नहीं” की सूची लिखें: सेटिंग्स, टीमें, एडमिन पैनल, ईमेल सूचनाएँ, दूसरा फ़ीचर, डार्क मोड। लिख लेने से शनिवार को “ना” कहना आसान होता है।
- बिल्डर के लिए अपना पहला प्रॉम्प्ट ड्राफ़्ट करें (नीचे देखें)।
शनिवार: मुख्य लूप बनाएँ
- सुबह: नकली डेटा के साथ मुख्य लूप का पहला संस्करण चलाएँ। छोटे कदमों में बढ़ें: हर संदेश में एक बदलाव, फिर प्रीव्यू जाँचें।
- दोपहर: डेटाबेस जोड़ें ताकि रिफ़्रेश के बाद भी डेटा बचा रहे, और ऐप को खुद वास्तविक इनपुट के साथ इस्तेमाल करें। जो लूप को रोके उसे ठीक करें, और जो सिर्फ़ दिखावट का हो उसे नज़रअंदाज़ करें।
- शाम: अगर उपयोगकर्ताओं को अपना डेटा चाहिए तो लॉगिन जोड़ें। दो ब्राउज़र में दो खातों से जाँचें कि कोई दूसरे का डेटा नहीं देख सकता।
रविवार: इसे अजनबियों के लायक बनाएँ
- सुबह: एक सरल लैंडिंग सेक्शन: वह एक वाक्य, किसके लिए है, और साइन-अप बटन। अगर आपका सवाल भुगतान का है, तो भुगतान जोड़ें।
- दोपहर: फ़ोन पर जाँचें। खाली अवस्थाएँ (नया उपयोगकर्ता कुछ जोड़ने से पहले क्या देखता है) जितनी दिखती हैं उससे ज़्यादा मायने रखती हैं।
- दोपहर बाद: सुरक्षा और सामान्य जाँच: ब्राउज़र कोड में कोई API कुंजी नहीं, कोई ऐसा पेज नहीं जो दूसरे उपयोगकर्ताओं का डेटा दिखाए। फिर प्रकाशित करें।
- शाम: पाँच से दस लोगों को व्यक्तिगत रूप से भेजें, साथ में एक सवाल जिसका जवाब आप चाहते हैं।
क्या छोड़ें
वे चीज़ें जो ज़रूरी लगती हैं पर रुक सकती हैं:
- एडमिन डैशबोर्ड। अभी के लिए डेटाबेस सीधे देखें।
- सेटिंग्स और प्रोफ़ाइल। समझदार डिफ़ॉल्ट हार्ड-कोड करें।
- टीमें, भूमिकाएँ और आमंत्रण। पहले एकल-उपयोगकर्ता खाते।
- कई प्राइसिंग प्लान। एक कीमत, या मुफ़्त।
- ईमेल फ़्लो, लॉगिन के लिए जितना ज़रूरी है उससे आगे नहीं।
- इंटीग्रेशन। पहले परीक्षण के लिए CSV एक्सपोर्ट या कॉपी-पेस्ट काफ़ी है।
- परफ़ेक्ट डिज़ाइन। साफ़ और पढ़ने योग्य काफ़ी है। एक जैसा रंग और अच्छी जगह बहुत काम आती है।
- स्केल। दस उपयोगकर्ता किसी चीज़ पर ज़ोर नहीं डालेंगे।
AI बिल्डर के लिए पहला प्रॉम्प्ट
CoverCraft नाम का एक MVP बनाओ, जो नौकरी के लिए आवेदन करने वाले जूनियर डेवलपर्स के लिए है। मुख्य लूप: लॉगिन के बाद उपयोगकर्ता नौकरी का विवरण और अपने CV का टेक्स्ट चिपकाता है, एक लहजा चुनता है (औपचारिक या दोस्ताना), और एक संपादन योग्य, कॉपी करने योग्य टेलर्ड कवर लेटर पाता है। पत्र सर्वर पर AI_API_KEY नाम की कुंजी वाले AI प्रदाता से बनाओ, और कुंजी कभी ब्राउज़र में न दिखाओ। हर पत्र को नौकरी के शीर्षक और कंपनी के साथ डेटाबेस में सेव करो; हर उपयोगकर्ता अपनी सूची में सिर्फ़ अपने पत्र देखे। लैंडिंग सेक्शन में एक वाक्य में उत्पाद का परिचय और “शुरू करें” बटन हो। हर उपयोगकर्ता की सीमा प्रति दिन 10 पत्र, सर्वर पर लागू। डिज़ाइन साफ़ और सादा रखो, और फ़ोन पर अच्छा काम करे। कोई सेटिंग्स, टीमें या एडमिन पैनल न जोड़ो।
आख़िरी पंक्ति अहम है। AI बिल्डर अक्सर वे फ़ीचर जोड़ देते हैं जो आपने माँगे नहीं, और उन्हें बताना कि क्या नहीं बनाना है, पहला संस्करण छोटा रखता है। इस पर और जानकारी के लिए AI ऐप बिल्डर के लिए प्रॉम्प्ट कैसे लिखें देखें।
समय बचाने वाले सुझाव
- हर संदेश में एक बदलाव। बड़े, बहु-भाग वाले अनुरोध जाँचने और पलटने में कठिन होते हैं।
- हर बदलाव के बाद परखें, प्रीव्यू में, फ़ोन के आकार पर।
- बहस करने के बजाय रोलबैक करें। अगर कोई बदलाव गलत हुआ, तो आखिरी काम करने वाले संस्करण पर लौटें और ज़्यादा साफ़ तरीके से दोबारा माँगें।
- जोखिम भरे काम से पहले योजना मोड इस्तेमाल करें, जैसे लॉगिन या भुगतान जोड़ने से पहले।
- 80% पर पॉलिश बंद करें। जिस फ़ीचर को कोई इस्तेमाल ही नहीं करता, उसके बाकी 20% की पॉलिश बेकार है।
आम गलतियाँ
- बिना सवाल के शुरू करना, ताकि आप बता न सकें कि वीकेंड सफल रहा या नहीं।
- एक की जगह दो फ़ीचर, और दोनों अधूरे।
- “इस वीकेंड नहीं” की सूची बनाना, क्योंकि वह उत्पादक लगता है।
- डेटाबेस छोड़ देना, तो रिफ़्रेश पर सब गायब और परीक्षकों का काम खत्म।
- किसी को कभी न दिखाना। जो MVP निजी रहे, उसने आपको कुछ नहीं सिखाया।
- दोस्तों से “क्या तुम्हें पसंद आया?” पूछना। देखें कि वह समस्या वाले अजनबी असल में क्या करते हैं।
कब बिल्कुल न बनाएँ
कभी-कभी वीकेंड को न बनाने में खर्च करना बेहतर है। अगर विचार को एक फ़ॉर्म, एक स्प्रेडशीट और एक भुगतान लिंक से, या तीन ग्राहकों के लिए सेवा हाथ से करके परखा जा सकता है, तो पहले वही करें। बनाएँ जब मूल्य खुद सॉफ़्टवेयर में हो: एक वर्कफ़्लो, एक गणना, एक ऐसा जनरेटेड नतीजा जो मौजूदा टूल नहीं दे सकते। वीकेंड के बाद ऐप लॉन्च करके पहले उपयोगकर्ता कैसे पाएँ अगला कदम बताता है, और SaaS MVP कैसे बनाएं उचित खाते और सब्सक्रिप्शन जोड़ने के बारे में बताता है, जब विचार ने वह कमाया हो।
Mythex से बनाना
Mythex वीकेंड योजना के लिए अच्छा बैठता है: आप चैट में MVP का वर्णन करते हैं, एजेंट कोड लिखता है, और आप लाइव प्रीव्यू में परखते हैं, फ़ोन के आकार वाले दृश्य सहित। शुक्रवार की रात आइडिया को आकार देने के लिए Plan मोड उपयोगी है, और हर सफल बदलाव एक चेकपॉइंट के रूप में सेव होता है जिस पर आप लौट सकते हैं। जब आप डेटा सेव करवाना चाहते हैं, Mythex प्रोजेक्ट में एक Postgres डेटाबेस जोड़ता है। /test एजेंट से कहता है कि वह प्रीव्यू में एक उपयोगकर्ता की तरह क्लिक करे और टूटे प्रवाह बताए (App Testing)। प्रकाशित करने से पहले आप परीक्षकों को प्रीव्यू का शेयर लिंक भेज सकते हैं।
कुछ हिस्से आपको खुद लाने होते हैं: आपके उपयोगकर्ताओं का लॉगिन एक ऑथ तरीके से चलता है जिसे आप चुनते हैं, भुगतान आपके अपने Stripe खाते से होते हैं, और AI फ़ीचर आपकी अपनी मॉडल API कुंजी से। Free प्लान पहले दिन 10 क्रेडिट देता है और उसके बाद रोज़ 5, जो किसी व्यस्त वीकेंड में आपकी निर्माण सीमा तय कर सकता है; Pro हर महीने 100 क्रेडिट देता है। docs की विचार से लाइव ऐप तक यात्रा भी इसी तरह का रास्ता दिखाती है।
सवाल
क्या सचमुच एक वीकेंड में MVP बनाया जा सकता है?
आप एक मुख्य फ़ीचर का एक छोटा, काम करने वाला पहला संस्करण एक वीकेंड में बना सकते हैं, खासकर AI ऐप बिल्डर के साथ। आप एक पॉलिश्ड उत्पाद नहीं बनाएँगे, और बनाने की कोशिश भी नहीं करनी चाहिए। लक्ष्य है कुछ ऐसा जिसे असली लोग इस्तेमाल कर सकें, ताकि आप सीख सकें कि विचार और समय के लायक है या नहीं।
वीकेंड MVP में क्या छोड़ देना चाहिए?
वह सब जो मुख्य विचार को परखने के लिए ज़रूरी नहीं: सेटिंग्स पेज, टीमें और भूमिकाएँ, एडमिन डैशबोर्ड, कई प्राइसिंग प्लान, इंटीग्रेशन, सूचनाएँ और ज़्यादातर किनारे के मामले। एक अलग सूची बनाकर रखें।
क्या वीकेंड MVP में लॉगिन और भुगतान चाहिए?
सिर्फ़ तभी जब परीक्षण को उनकी ज़रूरत हो। अगर उपयोगकर्ताओं को अपना डेटा सेव करना है, तो सरल लॉगिन जोड़ें। अगर सवाल यह है कि लोग पैसे देंगे या नहीं, तो भुगतान लिंक या एक चेकआउट काफ़ी है; पूरी सब्सक्रिप्शन बिलिंग बाद में आ सकती है।
वीकेंड के बाद क्या करना चाहिए?
उसे उन लोगों के सामने रखें जिनसे आपने बनाने से पहले बात की थी, उन्हें उसे इस्तेमाल करते हुए देखें, और फ़ैसला उनके कहने से नहीं, उनके करने के आधार पर लें। फिर सबसे बड़ी समस्या ठीक करें या दिशा बदलें।