वेब ऐप, SaaS और MVP डेवलपमेंट

वेब ऐप या MVP प्रोजेक्ट में क्या-क्या शामिल है#

हम काम को आपके असली ब्रीफ़ के हिसाब से ढालते हैं। प्रस्ताव में साफ़ लिखा होता है कि इनमें से कौन-से डिलीवरेबल शामिल हैं, इनपुट कौन देगा और हर डिलीवरेबल कैसे स्वीकार किया जाएगा।

• पहले वर्ज़न का स्कोप: मुख्य वर्कफ़्लो, रोल और जो बाद के लिए रखा गया है
• मुख्य स्क्रीन, खाली, लोडिंग और एरर स्टेट के साथ डिज़ाइन की गई
• डेटा मॉडल, सर्वर-साइड एक्सेस नियम और उन्हें तोड़ने की कोशिश करने वाले टेस्ट
• अकाउंट, रोल और टीम इन्विटेशन
• प्रोवाइडर के सत्यापित कॉलबैक से पुष्ट किए गए पेमेंट या सब्सक्रिप्शन
• एडमिन व्यू, प्रोडक्ट एनालिटिक्स इवेंट और एरर मॉनिटरिंग
• डिप्लॉयमेंट, डॉक्यूमेंटेशन, और रिपॉज़िटरी व अकाउंट की हैंडओवर

पहले वेब ऐप, वेबसाइट या प्रोडक्ट डिज़ाइन?#

यह तब चुनें जब ग्राहकों या स्टाफ़ को प्रोडक्ट में साइन इन करके काम पूरा करना हो: कुछ खरीदना, बुक करना, जमा करना, मंज़ूर करना या मैनेज करना। अगर आपको ऐसी साइट चाहिए जो आपकी पेशकश समझाए और बेचे, तो वेब डेवलपमेंट बेहतर विकल्प है। अगर वर्कफ़्लो अभी तय नहीं है, तो प्रोडक्ट डिज़ाइन से शुरू करें और मुख्य स्क्रीन को यूज़र्स के साथ टेस्ट करने के बाद बिल्ड करें।

पहला वर्ज़न कैसे बनता है#

हम स्कोपिंग चरण से शुरू करते हैं: यूज़र और रोल, वह एक वर्कफ़्लो जिसे पहले वर्ज़न को पूरा करना है, हर कदम पर बनने वाला डेटा, और वे फ़ैसले जो लागत बदलते हैं, जैसे पेमेंट, इंटीग्रेशन और परमिशन। इसका नतीजा होता है लिखित स्कोप, क्लिक करके देखने लायक मुख्य स्क्रीन और एक रिलीज़ प्लान, जिसमें साफ़ लिखा होता है कि क्या बाद के लिए रखा गया है।

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

MVP के पहले वर्ज़न में क्या होना चाहिए?#

पहले वर्ज़न में वह सब होना चाहिए जो किसी असली यूज़र को एक वर्कफ़्लो पूरा करने के लिए चाहिए, और वह कुछ नहीं जो सिर्फ़ ऐसे स्केल पर मायने रखता है जहाँ आप अभी पहुँचे नहीं हैं। व्यवहार में ये पाँच चीज़ें हैं: वर्कफ़्लो के लिए ज़रूरी रोल वाले अकाउंट, मुख्य वर्कफ़्लो, एडमिन व्यू ताकि आपकी टीम बिना डेवलपर के रिकॉर्ड देख और ठीक कर सके, पेमेंट अगर बिज़नेस मॉडल पहले दिन से चार्ज करता है, और एनालिटिक्स इवेंट जो दिखाएँ कि यूज़र कहाँ रुक जाते हैं।

जो काम हाथ से हो सकता है या बाद में खरीदा जा सकता है, उसे टाल दें: नेटिव मोबाइल ऐप, एंटरप्राइज़ ग्राहकों के लिए सिंगल साइन-ऑन, कॉन्फ़िगर करने लायक परमिशन मैट्रिक्स, दूसरा इंटीग्रेशन, ऐप में चैट और ऐसी रिपोर्ट जो किसी ने माँगी ही नहीं। टाली गई हर चीज़ की स्कोप में एक पंक्ति फिर भी रहती है, ताकि डेटा मॉडल में उसके लिए जगह बची रहे।

ज़्यादातर प्रोडक्ट जाने-पहचाने मॉड्यूल से जोड़कर बनते हैं। दो पर ध्यान देना ज़रूरी है: बुकिंग और शेड्यूलिंग, और छोटे बिज़नेस के लिए लीड पाइपलाइन, जो आज पूछताछ को हाथ से ट्रैक करता है। दोनों सरल दिखते हैं, पर उनमें टाइम ज़ोन, स्टेटस और ओनरशिप के ऐसे फ़ैसले छिपे होते हैं जिन्हें कागज़ पर तय करना सस्ता पड़ता है।

Dardo कौन-सा स्टैक इस्तेमाल करता है, और कब अलग चुनता है?#

हमारा डिफ़ॉल्ट है शुरू से अंत तक TypeScript: सर्वर-रेंडर पेज और इंटरैक्टिव आइलैंड के लिए Astro, होस्टिंग और API के लिए Cloudflare Workers, डेटा के लिए Cloudflare D1 या Postgres, और एनालिटिक्स व एक्सपेरिमेंट के लिए PostHog। Superame Astro पर चलता है और उसकी रैंकिंग Neon Postgres में रहती है। एक भाषा और एक डिप्लॉयमेंट टारगेट छोटे प्रोडक्ट को चलाना और हैंडओवर करना आसान रखते हैं।

जब प्रोडक्ट की माँग हो, हम अलग चुनते हैं। दिन भर खुला रहने वाला भारी इंटरफ़ेस क्लाइंट-साइड React ऐप्लिकेशन को सही ठहरा सकता है, जैसा Shiimain प्रोटोटाइप में है। लंबे समय तक चलने वाले जॉब, भारी डेटा प्रोसेसिंग या किसी दूसरे फ़्रेमवर्क में काम करने वाली इन-हाउस टीम भी जवाब बदल देती है। अगर लॉन्च के बाद कोड आपके डेवलपर संभालेंगे, तो आमतौर पर उनका स्टैक ही चुना जाता है।

एक्सेस कंट्रोल हम सबसे पहले टेस्ट करते हैं। OWASP की Top 10:2025 में Broken Access Control पहले नंबर पर है, और रिपोर्ट के अनुसार जितने भी ऐप्लिकेशन टेस्ट किए गए, सभी में इसका कोई न कोई रूप मिला। हम हर रिक्वेस्ट पर सर्वर में परमिशन लागू करते हैं, डिफ़ॉल्ट रूप से मना करते हैं, हर क्वेरी को साइन-इन यूज़र के संगठन तक सीमित रखते हैं और ऐसे ऑटोमेटेड टेस्ट लिखते हैं जो किसी दूसरे ग्राहक के रिकॉर्ड पढ़ने की कोशिश करें।

वेब ऐप में पेमेंट कैसे काम करने चाहिए?#

पेमेंट की पुष्टि पेमेंट प्रोवाइडर सर्वर पर करता है; चेकआउट से लौटता ब्राउज़र कभी नहीं करता। Dardo के प्रकाशित काम में शामिल सार्वजनिक प्रोजेक्ट लीडरबोर्ड Superame इसी तरीके को दिखाता है। खरीदार Dodo Payments के होस्टेड चेकआउट पर भुगतान करते हैं, इसलिए कार्ड की जानकारी ऐप तक कभी नहीं पहुँचती। इसके बाद प्रोवाइडर एक साइन किया हुआ कॉलबैक भेजता है, और सर्वर क्रेडिट जोड़ने से पहले सिग्नेचर सत्यापित करता है और पेमेंट का ब्योरा जाँचता है।

रिफंड और विवाद भी इसी रास्ते से चलते हैं। प्रोवाइडर का हर इवेंट सिर्फ़ एक बार लागू होता है, इसलिए दो बार, देर से या क्रम से बाहर आने वाला कॉलबैक क्रेडिट को दो बार न जोड़ सकता है, न घटा सकता है। Superame अपनाए जाने या राजस्व के कोई आँकड़े प्रकाशित नहीं करता; यह इस बात का प्रमाण है कि पेमेंट लॉजिक कैसे बनाया गया है, बिक्री का नहीं।

• जो खरीदार रीडायरेक्ट से पहले टैब बंद कर देता है, उसे भी कॉलबैक आने पर क्रेडिट मिल जाता है।
• दोबारा भेजा गया या नकली कॉलबैक अस्वीकार कर दिया जाता है।
• रिफंड या विवाद ठीक उतना ही वापस करता है जितना मूल पेमेंट से मिला था।
• प्लान की सीमाएँ सर्वर पर जाँची जाती हैं, सिर्फ़ इंटरफ़ेस में छिपाई नहीं जातीं।
• टेस्ट और लाइव कीज़ अलग-अलग सीक्रेट हैं, जो रिपॉज़िटरी में कभी स्टोर नहीं की जातीं।

अपने ग्राहकों को उनके अपने डोमेन इस्तेमाल करने दें#

B2B SaaS के ग्राहक अक्सर प्रोडक्ट को अपने ही पते पर चाहते हैं, जैसे portal.theircompany.com। Cloudflare for SaaS इसे कस्टम होस्टनेम से संभालता है: Free, Pro और Business प्लान में 100 शामिल हैं, हर अतिरिक्त होस्टनेम की कीमत $0.10 है, और अधिकतम सीमा 50,000 है। वाइल्डकार्ड कस्टम होस्टनेम सिर्फ़ Enterprise में मिलते हैं।

आपका ग्राहक एक CNAME रिकॉर्ड जोड़ता है जो आपके टारगेट की ओर इशारा करता है। उस टारगेट की ओर इशारा करने के लिए A रिकॉर्ड का इस्तेमाल, जो रूट डोमेन को चाहिए होगा, डिफ़ॉल्ट रूप से समर्थित नहीं है, और एपेक्स प्रॉक्सिंग Enterprise का ऐड-ऑन है, इसलिए ज़्यादातर ग्राहकों को सबडोमेन इस्तेमाल करना चाहिए। सर्टिफ़िकेट HTTP, TXT या ईमेल से, या Delegated DCV से सत्यापित होते हैं, जो एक बार का रिकॉर्ड है और Cloudflare को उन्हें अपने आप रिन्यू करने देता है। इन्हें Let's Encrypt, Google Trust Services या SSL.com जारी करते हैं।

इसके आसपास का प्रोडक्ट वर्क भी उतना ही मायने रखता है: सिर्फ़ पेड प्लान डोमेन कनेक्ट कर सकते हैं, ऑनबोर्डिंग स्क्रीन पर जोड़ा जाने वाला सटीक रिकॉर्ड दिखता है, वेरिफ़िकेशन स्टेटस पेंडिंग और फ़ेल्ड स्थितियों को आसान भाषा में समझाता है, और जब किसी ग्राहक के DNS बदलने से सर्टिफ़िकेट रिन्यू नहीं हो पाता तो मॉनिटरिंग आपकी टीम को अलर्ट करती है। दूसरे होस्ट अलग सीमाएँ तय करते हैं: Vercel Hobby पर हर प्रोजेक्ट में 50 डोमेन की अनुमति देता है और Pro व Enterprise पर असीमित, 100,000 और 1,000,000 की सॉफ़्ट सीमाओं के साथ; Netlify हर साइट पर 50 से ज़्यादा डोमेन एलियास न रखने की सलाह देता है।

चुनने से पहले कुछ सवाल#

ब्लॉग से#

• SaaS के लिए कस्टम डोमेन: Cloudflare for SaaS से ग्राहकों को उनका अपना डोमेन इस्तेमाल करने दें

  Cloudflare for SaaS से ग्राहकों को उनका अपना डोमेन आपके SaaS पर पॉइंट करने दें: वैलिडेशन कैसे काम करता है, अक्टूबर 2026 तक इसकी लागत क्या है और यह कहाँ फेल होता है।