सेवा
कस्टम वेब एप्लिकेशन डेवलपमेंट
ऐसे प्लेटफ़ॉर्म जो असली लोड, असली डेटा और असली उपयोगकर्ताओं के नीचे टिके रहें।
हम जो बनाते हैं उसका ज़्यादातर हिस्सा वेब पर ही रहता है: कारोबार चलाने वाले आंतरिक प्लेटफ़ॉर्म, ग्राहक पोर्टल, असली परिचालन डेटा पर बने डैशबोर्ड, और ऐसी सार्वजनिक साइटें जिन्हें तेज़ और खोजे जाने लायक़ होना है। ये प्लगइन जोड़कर नहीं, एप्लिकेशन की तरह बनाए जाते हैं — और यही उन्हें एक साल बाद भी बदलने लायक़ रखता है।
फ़ैसला
यह कब सही फ़ैसला है।
फ़ैसला शायद ही कभी कस्टम बनाम कुछ नहीं का होता है। वह कस्टम बनाम एक प्लेटफ़ॉर्म और उन प्लगइनों का होता है जो उसकी और आपकी ज़रूरत के बीच की खाई पाटते हैं। वह ढेर शुरू करने में सस्ता और रखने में महँगा है: हर प्लगइन एक निर्भरता है, एक परफ़ॉर्मेंस लागत है और एक सुरक्षा सतह है, और यह जमावड़ा प्लेटफ़ॉर्म के अगले बड़े रिलीज़ पर टूट जाता है।
दूसरी लागत है ऊपरी सीमा। प्लेटफ़ॉर्म पर बने निर्माण तब तक तेज़ रहते हैं जब तक पहली ऐसी ज़रूरत न आ जाए जिसे प्लेटफ़ॉर्म व्यक्त नहीं कर सकता — और फिर जुगाड़ ही आर्किटेक्चर बन जाता है। कारोबार अपने सॉफ़्टवेयर के हिसाब से ख़ुद को ढालने लगते हैं, उल्टा नहीं — और यही वह स्थिति है जिससे बचने के लिए सॉफ़्टवेयर ख़रीदा गया था।
कस्टम तब अपनी क़ीमत वसूल करता है जब क्षेत्र का तर्क ही उत्पाद हो, जब डेटा मॉडल सचमुच आपका अपना हो, या जब परफ़ॉर्मेंस और इंटीग्रेशन इतने मायने रखते हों कि वे इंजीनियरिंग फ़ैसले बन जाएँ। जब इनमें से कुछ भी सच न हो, हम यही कह देते हैं — एक सोच-समझकर चुना गया प्लेटफ़ॉर्म उस निर्माण से बेहतर जवाब है जिसमें हमें ज़्यादा मज़ा आता।
आपको क्या मिलता है
काम में क्या शामिल है।
ऐसा आर्किटेक्चर जो बढ़ने पर भी टिके
डेटा मॉडल, सीमाएँ और डिप्लॉयमेंट पहली स्क्रीन से पहले तय होते हैं, क्योंकि यही वे फ़ैसले हैं जिन्हें पलटना महँगा पड़ता है।
जहाँ ज़रूरी हो वहाँ सर्वर-रेंडर्ड
ऐसे पेज जो क्रॉलर और धीमे फ़ोन दोनों को पूरे मिलें, और इंटरैक्टिविटी ऊपर से जुड़े — सामग्री दिखने की शर्त न बने।
असली ऑथराइज़ेशन
परमिशन हर अनुरोध पर सर्वर की ओर से लागू होती हैं, छिपाए गए मेन्यू आइटम से नहीं। और उन्हें तोड़ने की कोशिश करने वाले टेस्ट से जाँचा जाता है।
परफ़ॉर्मेंस एक तय बजट की तरह
Core Web Vitals को एक तय संख्या वाली निर्माण शर्त माना जाता है, लॉन्च के बाद चलाई जाने वाली रिपोर्ट नहीं।
शुरू से ही सुगम्यता
पहले कंपोनेंट से ही कीबोर्ड के रास्ते, फ़ोकस प्रबंधन, कंट्रास्ट और सिमैंटिक्स — जो बाद में जोड़ने से सस्ता है और खोज के लिए भी बेहतर।
प्रोडक्शन में चलाने लायक़
लॉगिंग, एरर रिपोर्टिंग, बैकअप और आज़माई हुई रिस्टोर प्रक्रिया — क्योंकि जो सॉफ़्टवेयर चलाया न जा सके वह पूरा नहीं हुआ।
स्टैक
हम इसे किससे बनाते हैं।
हर प्रोजेक्ट के हिसाब से चुने हुए। यहाँ कुछ भी डिफ़ॉल्ट रूप से नहीं लगाया जाता, और जो टीम आगे इसे संभालेगी वह समस्या जितनी ही मायने रखती है।
फ़्रंटएंड
TypeScript के साथ React या सर्वर-रेंडर्ड टेम्पलेट, हर प्रोजेक्ट के हिसाब से चुने हुए। कोई फ़्रेमवर्क डिफ़ॉल्ट रूप से नहीं लगाया जाता।
बैकएंड
Python, Node या .NET — समस्या जितना ही उस टीम को देखकर चुने गए जो आगे इसे संभालेगी।
डेटा
PostgreSQL या MySQL, जिसका स्कीमा जनरेट नहीं, डिज़ाइन किया गया हो। Redis वहाँ जहाँ कैशिंग सचमुच मदद करे।
इंफ़्रास्ट्रक्चर
Linux, nginx, और जहाँ जटिलता जायज़ हो वहाँ कंटेनर — आपके क्लाउड पर या हमारे।
डिलीवरी
वर्ज़न कंट्रोल, स्वचालित टेस्ट और पहले दिन से डिप्लॉय पाइपलाइन — तब नहीं जब तकलीफ़ होने लगे।
तुलना
प्लेटफ़ॉर्म बिल्ड बनाम कस्टम बिल्ड।
कुछ भी शुरू कराने से पहले यह तुलना कर लेनी चाहिए। बहुत से प्रोजेक्ट में बाईं ओर वाला विकल्प जीतता है, और हम यह कह देंगे।
| पहलू | प्लेटफ़ॉर्म + प्लगइन | कस्टम बिल्ड |
|---|---|---|
| कुछ उपयोगी बनने में लगने वाला समय | कुछ दिन। यह सचमुच एक फ़ायदा है और अक्सर यही फ़ैसला कर देता है। | कुछ हफ़्ते। तभी जायज़ जब प्लेटफ़ॉर्म वह नहीं कर सकता जो आपको चाहिए। |
| लागत का स्वरूप | कम और बार-बार आने वाली: लाइसेंस, हर सीट पर बढ़ोतरी, हर प्लगइन की सदस्यता, और इम्प्लीमेंटेशन पार्टनर | ज़्यादा और एक बार की, उसके बाद केवल होस्टिंग। कोड आपका है, कोई रनटाइम लाइसेंस नहीं। |
| ऊपरी सीमा | पहली ऐसी ज़रूरत पर आ जाती है जिसे प्लेटफ़ॉर्म व्यक्त नहीं कर सकता; फिर जुगाड़ ही आर्किटेक्चर बन जाता है | आपके अपने डिज़ाइन फ़ैसलों से तय, किसी और के रोडमैप से नहीं |
| निर्भरताओं का दायरा | हर प्लगइन ऐसा कोड है जो आपने नहीं लिखा, जिसका अपना रिलीज़ चक्र है, और जो आपकी सुरक्षा परिधि के अंदर है | केवल वही लाइब्रेरी जो आपने चुनीं, जाँची और पिन कीं |
| बड़े वर्ज़न अपग्रेड | टूटता प्लगइन का जमावड़ा है, और वह किसी और के तय समय पर टूटता है | आप तय करते हैं कब, और टेस्ट बता देते हैं कि क्या बदला |
| परफ़ॉर्मेंस और Core Web Vitals | थीम और प्लगइन का बोझ, जिसका इलाज एक और कैशिंग प्लगइन जोड़ना होता है | एक तय संख्या वाली निर्माण शर्त, जिसे पाइपलाइन में लागू किया जाता है |
यह कैसे चलता है
पहली बातचीत से लाइव होने तक।
इस तरह के काम के लिए अनुमानित। पायलट वैकल्पिक नहीं है — जब तक इस्तेमाल करने वाले यह न कहें कि यह टिकता है, कुछ भी स्विच नहीं किया जाता।
- 1-2 हफ़्ते
डिस्कवरी
हम पहले डेटा और भूमिकाओं का मॉडल बनाते हैं। लागत असल में यहीं बसती है और प्लेटफ़ॉर्म वाले निर्माण यहीं ग़लत होते हैं — स्क्रीन में नहीं।
- 4-8 हफ़्ते
मुख्य निर्माण
सबसे ज़्यादा ट्रैफ़िक वाला रास्ता शुरू से आख़िर तक, आपके असली डेटा के साथ, और पहले ही हफ़्ते से डिप्लॉय पाइपलाइन — तब नहीं जब तकलीफ़ होने लगे।
- 2-3 हफ़्ते
पायलट
एक टीम असली काम के लिए इसे इस्तेमाल करती है जबकि पुरानी प्रक्रिया चलती रहती है। उन्हें जो भी कमी मिलती है, वह किसी और के आने से पहले ठीक कर दी जाती है।
- 1-2 हफ़्ते
लॉन्च और हैंडओवर
बाक़ी उपयोगकर्ता, निगरानी और आज़माई हुई रिस्टोर वाले बैकअप, साथ में वह दस्तावेज़ीकरण जो किसी दूसरे डेवलपर को इसे संभालने देता है।
लॉन्च के बाद
क्या बदलता है।
- जिस ज़रूरत को प्लेटफ़ॉर्म व्यक्त नहीं कर पाता था, उसे अब कोई व्यक्ति स्प्रेडशीट में नहीं संभालता।
- पेज परफ़ॉर्मेंस वह आँकड़ा बन जाता है जो आपके हाथ में है, न कि कोई प्लगइन जिसके चलने की आप उम्मीद करते हैं।
- अपग्रेड एक घटना नहीं रह जाते, क्योंकि टूटने को प्लगइन का कोई जमावड़ा ही नहीं है।
- साठवें हफ़्ते में चाहा गया बदलाव लगभग उतना ही महँगा पड़ता है जितना छठे हफ़्ते में पड़ता।
जानबूझकर गुणात्मक रूप में बताया गया। हम ऐसे प्रतिशत सुधार प्रकाशित नहीं करते जिन्हें हम किसी नामित क्लाइंट से, उनकी सहमति के साथ, जोड़ न सकें।
सवाल
आम सवाल।
कस्टम वेब एप्लिकेशन में कितना समय लगता है?
एक केंद्रित आंतरिक प्लेटफ़ॉर्म आमतौर पर पहली बातचीत से प्रोडक्शन तक आठ से चौदह हफ़्ते लेता है। बड़े बहु-मॉड्यूल सिस्टम ज़्यादा समय लेते हैं और चरणों में दिए जाते हैं — पहला मॉड्यूल चालू रहता है जबकि अगला बन रहा होता है। हम चाहेंगे कि आप जल्दी कुछ असली इस्तेमाल करें, बजाय इसके कि सब कुछ तैयार होने का इंतज़ार करें।
क्या कोड हमारा होता है?
हाँ, पूरी तरह — रिपॉज़िटरी और डिप्लॉयमेंट कॉन्फ़िगरेशन सहित। कोई रनटाइम लाइसेंस नहीं है और कुछ भी किसी दूसरे डेवलपर को इसे संभालने से नहीं रोकता।
क्या आप हमारे मौजूदा सिस्टम के साथ काम कर सकते हैं?
आमतौर पर हाँ। ज़्यादातर काम किसी पहले से मौजूद चीज़ के साथ इंटीग्रेशन से शुरू होते हैं — कोई अकाउंटिंग पैकेज, कोई ईआरपी, कोई पुराना डेटाबेस। एक साथ सब कुछ बदल देना शायद ही कभी सही फ़ैसला होता है, और चरणबद्ध रास्ता ज़्यादा सुरक्षित है।
लॉन्च के बाद क्या होता है?
एक सहायता अवधि शामिल होती है, जिसके बाद ज़्यादातर क्लाइंट बदलावों और निगरानी के लिए रिटेनर लेते हैं। इनमें से कोई भी बंधन नहीं है: कोड आपका है और इतना दस्तावेज़ीकृत है कि कोई और उसे आगे ले जा सके।
क्या हमें बस कोई प्लेटफ़ॉर्म ही नहीं ले लेना चाहिए?
अक्सर हाँ। अगर आपका डेटा मॉडल प्लेटफ़ॉर्म में बैठ जाता है और आपकी ख़ासियत सॉफ़्टवेयर नहीं है, तो प्लेटफ़ॉर्म तेज़ और सस्ता है और हम यही कहेंगे। कस्टम तब अपनी क़ीमत वसूल करता है जब क्षेत्र का तर्क ही उत्पाद हो, जब डेटा मॉडल सचमुच आपका अपना हो, या जब इंटीग्रेशन और परफ़ॉर्मेंस सेटिंग्स नहीं बल्कि इंजीनियरिंग की समस्याएँ हों।
अगर बीच में हमारी ज़रूरतें बदल जाएँ तो क्या होगा?
बदलेंगी, और योजना यह मानकर ही चलती है। हर चरण की सीमा पर, जो सीखा गया उसके साथ दोबारा अनुमान लगाया जाता है — इसीलिए हम पूरे दायरे पर एक तय दाम के बजाय हर चरण पर एक ऊपरी सीमा वाला दाम पसंद करते हैं; क्योंकि पहला या तो जोखिम के लिए बढ़ा-चढ़ाकर रखा जाता है या पहली बार कुछ बदलते ही झगड़े की ओर जाता है।