01 नव॰ 2025·8 मिनट
7 दिनों में Ecommerce MVP: असली भुगतान के साथ एक छोटा स्टोर शिप करें
7-दिनों में ईकॉमर्स MVP: कैटलॉग, चेकआउट, असली भुगतान, बेसिक एडमिन, और सुरक्षित रिलीज़ का दिन-दर-दिन प्लान।
7-दिनों में ईकॉमर्स MVP: कैटलॉग, चेकआउट, असली भुगतान, बेसिक एडमिन, और सुरक्षित रिलीज़ का दिन-दर-दिन प्लान।
new, paid, shipped, refunded)।\n\nउदाहरण: आप तीन मोमबत्तियाँ बेचते हैं। हर एक की एक फोटो और एक कीमत है। एक खरीदार दो जोड़ता है, $5 फ्लैट शिपिंग देखता है, अपना पता दर्ज करता है, भुगतान करता है, फिर आप लेबल प्रिंट करने के बाद ऑर्डर को शिप्ड मार्क करते हैं।\n\nअगर आप vibe-coding प्लेटफ़ॉर्म जैसे Koder.ai का उपयोग कर रहे हैं, तो प्रॉम्प्ट सख्त रखें: “सिर्फ़ ये पेज, सिर्फ़ ये फ़ील्ड, कोई अकाउंट नहीं, कोई कूपन नहीं, कोई विज़लिस्ट नहीं।”\n\n## भुगतान: सरल और स्थिर रखें\n\nभुगतनों में क्रिएटिविटी से बचें। एक ऐसा प्रदाता चुनें जिसे आप जल्दी ऑनबोर्ड कर सकें और कार्ड भुगतान ही शिप करें। डिजिटल वॉलेट, बाय-नाउ-पे-लेटर, और बैंक ट्रांसफर बाद में आ सकते हैं।\n\nसबसे बड़ा चुनाव भुगतान फ्लो है:\n\n- Hosted checkout आमतौर पर सबसे तेज़ और सबसे सुरक्षित होता है, क्योंकि प्रदाता अधिक संवेदनशील UI को हैंडल करता है।\n- Embedded कार्ड फॉर्म बेहतर दिख सकते हैं, पर वे अधिक एज केस और सुरक्षा काम जोड़ते हैं।\n\nभुगतनों को एक छोटे सेट के स्टेट्स की तरह समझें जिन्हें आप एक नज़र में समझ सकें: created, paid, failed, canceled, refunded।\n\nसिर्फ़ वही स्टोर करें जो reconciliation और सपोर्ट के लिए चाहिए: प्रदाता payment ID, वैकल्पिक प्रदाता customer/session ID, राशि, मुद्रा, और आपका आंतरिक order ID। कच्चे कार्ड डेटा को कभी स्टोर न करें, और अपने खुद के भुगतान फ़ील्ड तब तक न जोड़ें जब तक कि सचमुच ज़रूरत न हो।\n\nWebhooks ऑर्डर्स को विश्वसनीय बनाते हैं। चेकआउट के बाद, ब्राउज़र रिडायरेक्ट को “paid” मानने की गलती न करें। एक webhook हैंडलर जोड़ें जो इवेंट को सत्यापित करे, फिर मिलते-जुलते ऑर्डर को paid मार्क करे।\n\nरी-ट्राइज के तहत सुरक्षित बनाएं। Webhooks बार-बार डिलीवर होंगे, इसलिए आपका हैंडलर idempotent होना चाहिए: अगर ऑर्डर पहले ही paid है तो उसे कुछ न करें और फिर भी success लौटाएँ।\n\nअगर आप तेज़ी से चैट-ड्रिवन बिल्डर जैसे Koder.ai के साथ बना रहे हैं, तो पहले पेमेंट स्टेट्स और न्यूनतम फ़ील्ड परिभाषित करें, फिर webhook endpoint और order update लॉजिक जेनरेट करें। यह स्पष्टता क्लासिक गड़बड़ी (पे किए ग्राहक, अनपे ऑर्डर, और घंटों का मैनुअल चेक) से बचाएगी।\n\n## 7-दिन के बिल्ड के लिए दिन-ब-दिन प्लान\n\nDay 1: स्कोप लॉक करें। एक पेज का स्पेक लिखें: एक शॉपर क्या कर सकता है, एक एडमिन क्या कर सकता है, और क्या आउट ऑफ़ स्कोप है। एक पेमेंट प्रदाता चुनें। यह तय करें कि आप टोटल कैसे कैलकुलेट करेंगे (अब टैक्स/शिपिंग या बाद में)। पांच मुख्य स्क्रीन स्केच करें: कैटलॉग, प्रोडक्ट पेज, कार्ट, चेकआउट, पेमेंट रिज़ल्ट।\n\nDay 2: कैटलॉग शिप करें। सिर्फ़ ज़रूरी फ़ील्ड के साथ प्रोडक्ट स्टोर करें: name, price, currency, photo, short description, active flag। एक "all products" पेज (या सरल कैटेगरी) और एक प्रोडक्ट डिटेल पेज बनाएं। लगभग 10 टेस्ट प्रोडक्ट्स सीड करें ताकि आप असली फ्लो टेस्ट कर सकें।\n\nDay 3: कार्ट और ऑर्डर ड्राफ्ट। add/remove और quantity changes लागू करें। जब चेकआउट शुरू हो, तो एक order draft बनाएं और प्राइस का स्नैपशॉट लें ताकि बाद में प्रोडक्ट एडिट्स पुराने ऑर्डर्स को न बदलें। ग्राहक ईमेल और शिपिंग पता जल्दी कैप्चर करें।\n\nDay 4: टेस्ट मोड में भुगतान। चेकआउट को पेमेंट क्रिएशन से कनेक्ट करें। success, canceled, और failed पेमेंट्स का हैंडल करें। ऑर्डर पर पेमेंट स्टेटस सेव करें। ऑर्डर नंबर और अगले कदम के साथ एक स्पष्ट कन्फर्मेशन पेज दिखाएँ।\n\nDay 5: fulfillment के लिए बेसिक एडमिन। एडमिन छोटा रखें: प्रोडक्ट create/edit/disable, एक ऑर्डर्स लिस्ट स्टेटस अपडेट्स के साथ (paid, packed, shipped, refunded), और भेजने के लिए ज़रूरी जानकारी वाला एक सरल "view order" पेज।\n\nDay 6: डिप्लॉयमेंट और सुरक्षा। अलग staging और production एनवायरनमेंट सेट करें, लॉग ऑन करें, और टेस्ट कार्ड्स के साथ पूरे फ्लो का rehearsal करें। रोलबैक प्लान पहले लिख लें।\n\nDay 7: लाइव जाएँ (छोटा, नियंत्रित)। एक वास्तविक कम-वैल्यू खरीदारी के साथ अंतिम रन-थ्रू करें, ईमेल/रसीद की पुष्टि करें, फिर पहले छोटे ऑडियंस के लिए स्टोर खोलें। अगर आप Koder.ai का उपयोग करते हैं, तो हर बड़े परिवर्तन से पहले स्नैपशॉट लें ताकि चेकआउट टूटने पर आप जल्दी रोलबैक कर सकें।\n\n## उस गंदे ऑर्डर से बचने के लिए आपको जो डेटा स्टोर करना चाहिए\n\nसप्ताह-एक स्टोर ऑर्डर स्पष्टता पर जीवित रहता है। एक बार किसी ने भुगतान कर दिया, आपको जल्दी जवाब देने योग्य होना चाहिए: उन्होंने क्या खरीदा, कहाँ भेजना है, और वर्तमान स्थिति क्या है?\n\nछोटा, बोरिंग डेटा मॉडल से शुरू करें। ये पाँच रिकॉर्ड लगभग सब कुछ कवर करते हैं:\n\n- Product: id, title, price, currency, active\n- Customer: id, email, name (optional)\n- Order: id, customer_id (या email), shipping address fields, status, totals snapshot, created_at\n- OrderItem: order_id, product_id, title_snapshot, unit_price_snapshot, quantity\n- Payment: order_id, provider, provider_payment_id, amount, currency, status, raw_event_id\n\nएड्रेस को मिनिमल रखें ताकि चेकआउट तेज़ रहे। आमतौर पर आपको सिर्फ़ name, line1, city, postal code, और country चाहिए। फोन वैकल्पिक रखें जब तक कि आपके कैरियर को इसकी ज़रूरत न हो।\n\nखरीद समय पर टोटल्स को स्नैपशॉट के रूप में रिकॉर्ड करें। बाद में Product तालिका से टोटल्स रीकैल्कुलेट न करें। कीमतें बदलती हैं, शिपिंग रेट्स बदलती हैं, और आपके पास “ग्राहक ने X भुगतान किया पर ऑर्डर अब Y दिखाता है” वाली स्थिति बन जाएगी।\n\nस्पष्ट स्टेटस का उपयोग करें जो fulfillment से मेल खाते हों, न कि पेमेंट-प्रदाता शब्दावली से: new, paid, packed, shipped, canceled। refunded तब ही जोड़ें जब आप सचमुच इसका समर्थन करते हों।\n\nपेमेंट अपडेट्स में idempotency की योजना बनाएं। वही webhook दो बार या आउट-ऑफ-ऑर्डर आ सकता है। प्रदाता से एक यूनिक इवेंट ID स्टोर करें और डुप्लिकेट्स को अनदेखा करें।\n\nउदाहरण: एक webhook पेमेंट को दो बार “succeeded” मार्क करता है। आपका सिस्टम दो शिपमेंट नहीं बनाना चाहिए और दो कन्फर्मेशन ईमेल नहीं भेजना चाहिए। अगर आप Koder.ai पर Go बैकेंड और PostgreSQL के साथ बना रहे हैं, तो (provider, raw_event_id) पर यूनिक कॉन्स्ट्रेंट और स्टेटस अपडेट के चारों ओर एक ट्रांज़ैक्शन अक्सर पर्याप्त होता है।\n\n## बेसिक एडमिन: सिर्फ़ वही जो ऑर्डर पूरा करने में मदद करे\n\nएडमिन कोई “डैशबोर्ड” नहीं है। यह एक छोटा बैक रूम है जहाँ आप तीन सवालों का तेज़ उत्तर दें: क्या बिक रहा है, क्या पे किया गया, और क्या भेजना बाकी है।\n\nएक सिंगल एडमिन लॉगिन से शुरू करें। एक रोल काफी है। एक मजबूत पासवर्ड, बुनियादी रेट लिमिटिंग, और एक छोटा सत्र टाइमआउट उपयोग करें। इस सप्ताह स्टाफ़ प्रबंधन और परमिशन छोड़ दें। अगर आपको किसी दूसरे व्यक्ति की जरूरत है, तो जानबूझकर एक्सेस शेयर करें और बाद में पासवर्ड रोटेट करें।\n\nप्रोडक्ट प्रबंधन सरल रखें: प्रोडक्ट बनाएं/एडिट करें, एक मुख्य छवि अपलोड करें, कीमत सेट करें, उपलब्धता टॉगल करें। इन्वेंटरी काउंट तब तक न बनाएं जब तक कि आपके पास वे वास्तविक काउंट न हों। एक इन-स्टॉक/आउट-ऑफ-स्टॉक स्विच आमतौर पर ओवरसेलिंग रोक देता है।\n\nआपकी ऑर्डर्स व्यू को packing slip की तरह पढ़ना चाहिए। ऑर्डर ID या ग्राहक ईमेल से सर्च करना आसान बनाएं, फिर दिखाएँ:\n\n- ग्राहक का नाम, ईमेल, शिपिंग पता\n- आइटम्स, मात्राएँ, और फाइनल टोटल्स (शिपिंग और टैक्स सहित)\n- पेमेंट स्टेटस (paid, failed, refunded)\n- फुलफिलमेंट स्टेटस (new, packed, shipped)\n- टाइमस्टैम्प और एक छोटा आंतरिक नोट\n\nस्टेटस के लिए दो बटन रखें: “Mark packed” और “Mark shipped।” जब आप shipped मार्क करेंगे, तो वैकल्पिक रूप से एक ट्रैकिंग नोट स्टोर करें (कैरियर + ट्रैकिंग कोड, या "Local pickup arranged")। ऑटोमेटेड ईमेल तब तक रोकें अगर वे आपकी गति घटाने वाले हों।\n\nCSV एक्सपोर्ट वैकल्पिक है। केवल तभी जोड़ें जब आप जानते हैं कि आप इसे पहले सप्ताह में उपयोग करेंगे।\n\nअगर आप एक बिल्ड टूल जैसे Koder.ai का उपयोग कर रहे हैं, तो एडमिन को उसी ऐप में रखें, पर उसे एक प्रोटेक्टेड रूट के पीछे गेट करें और एक वैध सत्र आवश्यक रखें।\n\n## स्टेप-बाय-स्टेप: पहला सफल भुगतान बनाएं\n\nटेस्ट मोड में शुरू करें। आपका लक्ष्य “एक चेकआउट पेज” नहीं होना चाहिए। आपका लक्ष्य एक ऑर्डर है जो पेड हो, रिकॉर्ड हो, और पूरा करने के लिए तैयार हो।\n\nएक कड़ा नियम बनाएं: अपने सर्वर पर कभी कच्चे कार्ड विवरण न स्टोर करें। संवेदनशील डेटा सीधे पेमेंट प्रदाता को जाए इसलिए होस्टेड चेकआउट या क्लाइंट-साइड टोकनाइजेशन का उपयोग करें।\n\n### आपके पहले पेड ऑर्डर तक का रास्ता\n\n1. सर्वर पर एक टेस्ट प्रोडक्ट और प्राइस बनाएं। चेकआउट को ब्राउज़र से नहीं बल्कि आपकी डेटाबेस से प्राइस फेच करनी चाहिए।\n2. टेस्ट मोड में एक चेकआउट सेशन शुरू करें। आपका बैकएंड पेमेंट सेशन बनाता है और केवल वही लौटाता है जिसकी क्लाइंट को रीडायरेक्ट करने के लिए ज़रूरत है।\n3. डबल क्लिक से बचाव करें। पहली क्लिक के बाद Pay बटन डिसेबल करें। सर्वर-साइड idempotency की उपयोग करें (उदाहरण: कार्ट ID + एक छोटा टाइम विंडो) ताकि डुप्लिकेट्स अलग चार्ज न बनाएं।\n4. सर्वर पर पेमेंट सत्यापित करें। प्रदाता webhook को source of truth मानें। एक ऑर्डर को तभी paid मार्क करें जब आप इवेंट की सच्चाई और अपेक्षित राशि/मुद्रा से मिलान कर लें।\n4. फैलियर पाथ्स का टेस्ट करें। एक फेल्ड पेमेंट, एक कैंसिल्ड चेकआउट, और एक एक्सपायर्ड सेशन चलाएँ। हर एक का परिणाम एक स्पष्ट ऑर्डर स्टेट होना चाहिए, कोई रहस्य नहीं।\n\n### त्रुटियों को आसानी से ठीक करने योग्य बनाएं\n\nपेमेंट त्रुटियों को उस संदर्भ के साथ लॉग करें जिसे आप एक्शन ले सकें: ऑर्डर ID, सेशन ID, ग्राहक ईमेल (यदि उपलब्ध), अपेक्षित टोटल, प्रदाता त्रुटि कोड, और एक छोटा संदेश जैसे "Amount mismatch" या "Webhook signature invalid"।\n\nउदाहरण: एक ग्राहक दो मग खरीदने की कोशिश करता है। आपका सर्वर $24 + शिपिंग कैलकुलेट करता है, सेशन बनाता है, और ऑर्डर को pending के रूप में रिकॉर्ड करता है। अगर ग्राहक पेज बंद कर देता है, तो ऑर्डर canceled हो जाता है। अगर वे भुगतान करते हैं, तो webhook इसे paid में बदल देता है और आप उसे भरोसे के साथ पूरा कर सकते हैं।\n\n## एक वास्तविक रूप से पालन करने योग्य सुरक्षित डिप्लॉयमेंट वर्कफ़्लो\n\nजब आपके पास केवल एक हफ्ता हो, तो डिप्लॉयमेंट्स चुपचाप वही बन सकते हैं जो चेकआउट तोड़ दे। लक्ष्य कोई भव्य DevOps नहीं है। यह एक दोहराने योग्य रूटीन है जो सरप्राइज़ घटाता है और आपको एक एस्केप हैच देता है।\n\nदो एनवायरनमेंट सेट करें: staging और production। Staging को जितना संभव हो production जैसा बनाएं: वही सेटिंग्स, वही टेम्पलेट्स, वही टैक्स/शिपिंग नियम, पर पेमेंट टेस्ट मोड में। अंतिम चेक staging में करें, फिर उसी बिल्ड को production में प्रमोट करें।\n\nवर्ज़नड रिलीज़ का उपयोग करें। भले ही यह सिर्फ v1, v2, v3 ही हो, हर रिलीज़ को टैग करें और पिछली को तैयार रखें। रोलबैक एक एक्शन होना चाहिए: पिछले बिल्ड पर वापस स्विच करें या स्नैपशॉट restore करें। अगर आपका प्लेटफ़ॉर्म स्नैपशॉट और रोलबैक सपोर्ट करता है (Koder.ai करता है), तो हर प्रोडक्शन रिलीज से पहले स्नैपशॉट लेना आदत बनाएं।\n\nMVP सप्ताह के दौरान डेटाबेस मिग्रेशन को जोखिम भरा मानें। बैकवर्ड-कम्पैटिबल बदलाव प्राथमिकता दें: नई टेबल्स या कॉलम जोड़ें, अभी नाम बदलना या हटाना न करें, और पहले नया कोड पाथ्स काम करने तक पुराने पाथ्स रखें। अगर बैकफिल करना ज़रूरी है, तो उसे अलग जॉब में करें, रिक्वेस्ट के अंदर नहीं।\n\nसीक्रेट्स को अपने रेपो से बाहर रखें। API कीज़, webhook साइनिंग सीक्रेट्स, डेटाबेस URLs, और एडमिन पासवर्ड के लिए environment variables या सीक्रेट मैनेजर का उपयोग करें।\n\nरिलीज़ चेकलिस्ट:\n\n- स्टेजिंग चेकआउट एंड-टू-एंड एक टेस्ट कार्ड और एक webhook इवेंट के साथ वर्क करता है यह कन्फ़र्म करें\n- स्टेजिंग पर माईग्रेशन्स चलाएँ, फिर प्रोडक्शन पर, और पुष्टि करें कि ऑर्डर क्रिएशन अभी भी काम करता है\n- ईमेल (ऑर्डर कन्फर्मेशन, फेल्ड पेमेंट) दिखाएँ और जांचें\n- प्र रिलीज़ स्नैपशॉट लें और रिलीज़ वर्ज़न नोट करें\n- एक त्वरित सेकंडरी रिव्यू करें: एक व्यक्ति शिप करे, दूसरा लिस्ट चेक करे\n\n## सामान्य जाल जो 7-दिन MVP को धीमा करते हैं\n\nसबसे तेज़ रास्ता 7-दिन लक्ष्य चूकने का यह है कि आप "अच्छी" सुविधाएँ बनाएं जो चुपचाप मनी फ्लो को तोड़ दें। मकसद एक ऐसा स्टोर है जो भुगतान ले, एक विश्वसनीय ऑर्डर बनाए, और आपको उसे पूरा करने दे।\n\nएक आम गलती ब्राउज़र को अंतिम कीमत तय करने देना है। अगर टोटल्स, डिस्काउंट, या शिपिंग क्लाइंट पर कैलकुलेट किए जा रहे हैं, तो कोई एक दिन गलत राशि भर देगा। सर्वर को सिंगल सोर्स ऑफ ट्रूथ बनाएं: प्रोडक्ट IDs और मात्राओं से ऑर्डर रीबिल्ड करें, फिर पेमेंट बनाने से पहले टोटल्स फिर से कैलकुलेट करें।\n\nशिपिंग और टैक्स नियम भी समय खा सकते हैं। टीमें कई देशों और एज केस सपोर्ट करने की कोशिश में दिन गवा देती हैं। सप्ताह-एक के लिए एक सरल नियम चुनें और उस पर टिके रहें।\n\nपेमेंट्स चेकआउट में "काम" कर सकते हैं पर ऑपरेशंस में फेल हो सकते हैं अगर webhooks गायब हों। एक ग्राहक भुगतान करता है, पर आपका DB ऑर्डर को paid नहीं मार्क करता, तो fulfillment अटक जाता है। Webhook हैंडलिंग को आवश्यक मानें।\n\nपाँच जाल जो देखना चाहिए:\n\n- क्लाइंट-साइड टोटल्स पर भरोसा करना बजाय सर्वर पर रीकैल्कुलेट करने के\n- मांग से पहले जटिल शिपिंग और टैक्स टेबल बनाना\n- वेबhooks छोड़ना और सिर्फ़ “payment succeeded” रिडायरेक्ट पर भरोसा करना\n- एक स्पष्ट ऑर्डर कन्फर्मेशन संदेश या ईमेल भूलना\n- बिना रोलबैक पाथ के सीधे प्रोडक्शन पर डिप्लॉय करना\n\nउदाहरण: एक ग्राहक भुगतान पूरा करता है, फिर success पेज लोड होने से पहले टैब बंद कर देता है। बिना webhooks के, वे मान लेते हैं कि यह फेल हुआ, दोबारा कोशिश करते हैं, और आप डुप्लिकेट चार्ज का सामना कर सकते हैं।\n\nअगर आप Koder.ai के साथ बना रहे हैं, तो स्नैपशॉट और रोलबैक को अपनी दिनचर्या में इस्तेमाल करें: छोटे बदलाव शिप करें, एक ज्ञात अच्छा वर्शन रखें, और कुछ भी टूटने पर तेज़ी से recover करें।\n\n## लाइव भुगतान चालू करने से पहले तेज़ जांचें\n\nपहले स्टेजिंग में ये जांचें, फिर लाइव स्विच से ठीक पहले इन्हें दोहराएँ। लक्ष्य साधारण है: एक ग्राहक एक बार भुगतान करे, आप उसे एक बार रिकॉर्ड करें, और आप उसे पूरा कर सकें।\n\nखरीदार पथ से शुरू करें। एक प्रोडक्ट कार्ट में जोड़ें, चेकआउट पूरा करें, और सुनिश्चित करें कि आप एक स्पष्ट सफलता पेज पर land होते हैं। पुष्टि करें कि आप एडमिन में सही टोटल्स के साथ पेड ऑर्डर देख सकते हैं।\n\nफिर webhooks को मुश्किल तरीके से टेस्ट करें: देरी और retries। Webhooks देर से आ सकते हैं, दो बार आ सकते हैं, या आउट-ऑफ-ऑर्डर आ सकते हैं। आपकी ऑर्डर अपडेट लॉजिक idempotent होनी चाहिए ताकि retries कभी डुप्लिकेट पेड ऑर्डर न बनाएँ।\n\nप्री-लॉन्च चेकलिस्ट:\n\n- एक टेस्ट ऑर्डर एंड-टू-एंड प्लेस करें और पुष्टि करें कि वह एडमिन में ट्रांज़ैक्शन/पेमेंट ID के साथ दिख रहा है\n- उसी webhook इवेंट को फिर से भेजें और पुष्टि करें कि कुछ डुप्लिकेट नहीं हुआ\n- एक प्रोडक्ट डिसेबल करें और पुष्टि करें कि वह गायब हो गया है और खरीदा नहीं जा सकता\n- एडमिन में, एक ऑर्डर को स्टेटस (new -> paid -> shipped) से गुज़ारें और एक आंतरिक नोट जोड़ें\n- एक छोटा बदलाव डिप्लॉय करें और मिनटों में रोलबैक करें बिना ऑर्डर डेटा खोए\n\nकुछ भी घोषित करने से पहले एक वास्तविक लाइव चार्ज करें। एक वास्तविक कार्ड, एक छोटी राशि, और अपना खुद का शिपिंग पता उपयोग करें। आपको ऑर्डर को एक बार, साफ़ टाइमस्टैम्प और स्टेटस के साथ ठीक से दिखना चाहिए।\n\nअगर आप Koder.ai का उपयोग कर रहे हैं, तो स्नैपशॉट के साथ यह अभ्यास करें: डिप्लॉय करें, एक ऑर्डर रखें, रोल बैक करें, और पुष्टि करें कि मौजूदा ऑर्डर्स अभी भी सही तरीके से लोड होते हैं।\n\n## उदाहरण परिदृश्य: एक छोटा स्टोर जो इस सप्ताह भेज सकता है\n\nकल्पना करें कि एक छोटा कॉफ़ी रोस्टर 12 बैग कॉफ़ी ऑनलाइन बेचना चाहता है। उन्हें सब्सक्रिप्शन, रिव्यू, या लॉयल्टी प्रोग्राम की ज़रूरत नहीं है। उन्हें एक सरल स्टोर चाहिए जो असली पैसे ले और साफ़ ऑर्डर बनाए जिन्हें वे पूरा कर सकें।\n\nदूसरे दिन तक, कैटलॉग जितना जरूरी है उतना अच्छा होना चाहिए अगर हर प्रोडक्ट के पास एक स्पष्ट फोटो, एक कीमत, और एक छोटा विवरण (roast level, tasting notes, bag size) हो। विकल्प न्यूनतम रखें: प्रति प्रोडक्ट एक आकार और एक शिपिंग विकल्प (उदाहरण: एक देश में फ्लैट-रेट शिपिंग)।\n\nचौथे दिन तक, चेकआउट एक काम करेगा: शिपिंग विवरण एकत्र करना, कार्ड पेमेंट लेना, और कस्टमर को एक कन्फर्मेशन पेज दिखाना जिसे वे स्क्रीनशॉट कर सकें। एक ऑर्डर ID और छोटा सारांश (आइटम्स, टोटल, शिपिंग पता) दिखाएँ। अगर ग्राहक सपोर्ट को ईमेल करता है, तो वही ऑर्डर ID सबसे तेज़ तरीका है यह पता लगाने का कि क्या हुआ।\n\nपाँचवें दिन तक, एडमिन जानबूझकर सादा रहता है। रोस्टर साइन इन करते हैं, नए ऑर्डर्स देखते हैं, और ऑर्डर्स को paid, packed, shipped में ले जाते हैं। ट्रैकिंग बाद में आ सकती है। पहले सप्ताह में, "Shipped via postal service, label printed at 3:10pm" जैसा नोट अक्सर काफी होता है।\n\nयह वही स्कोप है जो चैट-फर्स्ट बिल्डर्स जैसे Koder.ai के साथ भी अच्छा काम करता है: स्क्रीन का छोटा सेट, टेबल का छोटा सेट, और एक स्पष्ट वर्कफ़्लो।\n\nसप्ताह 2 के विचार जिन्हें प्रतीक्षा करना चाहिए: डिस्काउंट कोड, बेहतर सर्च, इन्वेंटरी काउंट्स, और अधिक ऑटोमेटेड ईमेल। इन्हें केवल तब जोड़ें जब असली ऑर्डर्स बताएँ कि क्या मायने रखता है।\n\n## MVP लाइव होने के बाद अगले कदम\n\nपहला सप्ताह लाइव को एक लर्निंग स्प्रिंट के रूप में मानें। असली ऑर्डर्स सिस्टम से गुज़रने दें, फिर सबसे बड़ा friction हटाएँ जिसे आप साबित कर सकें।\n\nएक छोटा पायलट से शुरू करें: 10 पेड ऑर्डर्स का लक्ष्य रखें दोस्तों, सहकर्मियों, या एक छोटे ऑडियंस से जिन्हें आप सीधे मैसेज कर सकते हैं। हर व्यक्ति से पूछें कि वे कहाँ हिचकिचाए। एक साधारण शीट में ड्रॉप-ऑफ ट्रैक करें: product page -> cart -> checkout started -> payment success।\n\nपायलट के बाद केवल एक बदलाव एक साथ जोड़ें। शुरुआती सुधार आम तौर पर सरल होते हैं: स्पष्ट शिपिंग लागत, बेहतर प्रोडक्ट फ़ोटो, कम चेकआउट फ़ील्ड। अपनी नोट्स से अगला सबसे बड़ा ब्लॉकर चुनें, उसे ठीक करें, और एक और छोटा बैच चलाएँ।\n\nकस्टमर सपोर्ट भी आपको तेज़ी से बताएगा कि क्या गायब है। बार-बार आने वाले सवालों के लिए छोटे उत्तर रखें: मेरा ऑर्डर कहाँ है, क्या मैं रद्द कर सकता हूँ, भुगतान क्यों फेल हुआ, शिपिंग कितनी है और कब पहुँचेगा, क्या मैं पता बदल सकता हूँ।\n\nअगर आप बिना चेकआउट रिस्क के तेजी से iterate करना चाहते हैं, तो Koder.ai चैट से अगला वर्शन जेनरेट करने और स्नैपशॉट/रोलबैक का उपयोग करके बदलाव सुरक्षित तरीके से टेस्ट करने में मदद कर सकता है।एक “वास्तविक” MVP वह है जहाँ कोई अजनबी सफलतापूर्वक भुगतान कर सके, आप एक पेड ऑर्डर सही टोटल और शिपिंग विवरण के साथ देख सकें, और आप इसी दिन उसे पूरा कर सकें बिना अटकलों के।
अगर आप लगातार 10 ऑर्डर बिना मैन्युअल फिक्स के चला सकें, तो आप बहुत अच्छी स्थिति में हैं।
एक देश, एक मुद्रा, और एक भुगतान विधि (आमतौर पर कार्ड) चुनें। शिपिंग और टैक्स के लिए एक सरल नियम रखें (जैसे फ्लैट शिपिंग और टैक्स = 0 अगर संभव हो)।
स्कोप तब छोटा रहता है जब हर निर्णय यह सपोर्ट करे: product → cart → checkout → paid order → fulfillment।
शुरू करें:
अकाउंट्स, विज़लिस्ट, रिव्यू, कूपन, मल्टीपल मुद्राएँ और मल्टीपल पेमेंट मेथड छोड़ दें।
होस्टेड चेकआउट आमतौर पर 7-दिन MVP के लिए डिफॉल्ट है क्योंकि यह तेज़ है और सुरक्षा व UI के किनारों को घटाता है।
एम्बेडेड कार्ड फॉर्म अधिक “नेटिव” दिख सकते हैं, पर वे आम तौर पर अधिक फेल्यर मोड और सुरक्षा काम जोड़ते हैं।
Webhook को source of truth मानें। रिडायरेक्ट पेज UX के लिए सहायक होते हैं, पर वे भरोसेमंद नहीं हैं (टैब बंद हो सकते हैं, नेटवर्क फेल हो सकता है)।
इवेंट को सत्यापित करने और अपेक्षित राशि/मुद्रा से मिलाने के बाद ही ऑर्डर को paid मार्क करें।
एक idempotent webhook हैंडलर का उपयोग करें:
यह डबल ईमेल, डबल शिपमेंट और भ्रमित “दो बार भुगतान” स्थितियों को रोकेगा।
खरीद समय पर snapshots स्टोर करें:
बाद में प्रोडक्ट टेबल से टोटल्स को रीकैल्कुलेट न करें, क्योंकि कीमतें और नियम बदलते हैं और रिकॉर्ड मेल नहीं खाएंगे।
सरल और fulfillment-फोकस्ड स्टेटस रखें:
एडमिन को तीन सवालों का जवाब तेज़ी से देना चाहिए: क्या बिक रहा है, क्या पे किया गया है, क्या भेजना बाकी है।
न्यूनतम एडमिन फीचर्स:
पहले हफ्ते में चार्ट और जटिल रोल्स छोड़ दें।
एक सरल, सुरक्षित रूटीन:
यदि आप Koder.ai का इस्तेमाल कर रहे हैं, तो हर प्रमुख परिवर्तन से पहले लें ताकि आप जल्दी रोलबैक कर सकें।
new, paid, packed, shipped, canceled (सिर्फ़ तभी refunded जोड़ें जब आप सचमुच रिफंड सपोर्ट करते हों)created, paid, failed, canceled, refundedलक्ष्य यह है कि आप एक नज़र में जान लें कि अगला कदम क्या है।