अक्सर पूछे जाने वाले प्रश्न

MS WebX एक आईटी कंपनी है। हम वेबसाइट और वेब प्लेटफ़ॉर्म, iOS तथा Android के लिए नेटिव ऐप बनाते हैं और उनमें AI जोड़ते हैं — साथ में वह SEO काम भी, जिससे बनाया गया सिस्टम खोजा जा सके। हम अपने उत्पाद भी उसी प्लेटफ़ॉर्म पर चलाते हैं जो ग्राहकों के लिए इस्तेमाल होता है, यानी आधार असली उपयोग में परखा जा चुका होता है।

दोनों, और यह जानबूझकर है। जो हम देते हैं वह पहले हमारे अपने उत्पादों में चलता है — बहुभाषी पेज सिस्टम, API परत, एडमिन टूल, एनालिटिक्स। कोई भी क्लाइंट प्रोजेक्ट बिना परखी नींव पर शुरू नहीं होता, और कोर में कुछ टूटे तो वह ग्राहक से पहले हमें दिखता है।

तीन तरीकों से, जो यहाँ लिखी बातों पर निर्भर नहीं हैं। इस साइट का इम्प्रिंट पृष्ठ कंपनी की कानूनी जानकारी रखता है। हमारे उत्पाद सार्वजनिक हैं और हमसे संपर्क किए बिना इस्तेमाल किए जा सकते हैं। और संपर्क पृष्ठ उन्हीं लोगों तक पहुँचता है जो कोड लिखते हैं — बीच में कोई कॉल सेंटर नहीं।

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

छोटे और दिखने वाले कदमों में। काम एक स्टेजिंग वातावरण पर जाता है जिसे आप जब चाहें ब्राउज़र में खोल सकते हैं, और लाइव साइट पर तभी जाता है जब आप कहें। कोई भी तैयार उत्पाद को पहली बार प्रोजेक्ट के अंत में नहीं देखता — तब तक हर बदलाव महँगा हो चुका होता है।

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

हम पहले मौजूदा कोड पढ़ते हैं और फिर साफ़ बताते हैं कि सिस्टम के पूरे जीवनकाल में उसे आगे बढ़ाना सस्ता है या बदलना। दोनों जवाब आते हैं — विरासत में मिला कोड अक्सर बिलकुल ठीक होता है, बस उसका दस्तावेज़ीकरण खराब होता है। हम आदतन दोबारा बनाने की सलाह नहीं देते, क्योंकि वही सबसे महँगी चीज़ है जो कोई आपको बेच सकता है।

सर्वर पर PHP, ब्राउज़र में TypeScript, iOS और Android के लिए Flutter, डेटा के लिए MariaDB, और सर्विंग के लिए nginx तथा FrankenPHP। जानबूझकर मौजूदा और व्यापक रूप से जानी-पहचानी तकनीक, ताकि हमारे बाद कोई भी इसे संभाल सके। गुणवत्ता अच्छे इरादों से नहीं, मशीनों से तय होती है: स्टैटिक विश्लेषण बिना किसी छूट-सूची के सबसे सख़्त स्तर पर चलता है, और दो सौ से अधिक अपने नियम कोड को भटकते ही अस्वीकार कर देते हैं।

एक कोडबेस, जिसमें साझा कोर है और उसके ऊपर हर ब्रांड के लिए एक पतली परत। हर ब्रांड का अपना डिज़ाइन, अपना कंटेंट, अपना डेटाबेस और अपना डोमेन होता है, जबकि सुरक्षा सुधार, प्रदर्शन का काम और कोर की नई सुविधाएँ सब जगह एक साथ पहुँचती हैं, हर साइट में हाथ से कॉपी नहीं होतीं। नया ब्रांड जोड़ना कॉन्फ़िगरेशन और कंटेंट का काम है, फ़ोर्क का नहीं।

हाँ, और आमतौर पर इस वाक्य का जो अर्थ होता है उससे कहीं सख़्ती से। API एक बार PHP में परिभाषित होता है, और वेब का TypeScript क्लाइंट तथा ऐप का Dart क्लाइंट दोनों उसी परिभाषा से बनते हैं। कोई भी हाथ से नहीं लिखा जाता — लिंटर हाथ से लिखे API टाइप को अस्वीकार कर देता है। इसलिए ऐप चुपचाप सर्वर से अलग नहीं हो सकता: बेमेल होने पर बिल्ड टूटता है, प्रोडक्शन नहीं।

सचमुच हैं। हर पेज हर भाषा के लिए अलग रिकॉर्ड के रूप में मौजूद है, अपने टेक्स्ट और अपने URL के साथ — यह FAQ अंग्रेज़ी में /frequently-asked-questions पर है और जर्मन में /de/haeufig-gestellte-fragen पर, किसी अनुवाद पैरामीटर के पीछे नहीं। इसलिए हर भाषा वैसे लिखी जा सकती है जैसे उस बाज़ार में लोग सचमुच खोजते हैं, और एक भाषा बाकी सत्रह को छुए बिना सुधारी जा सकती है।

यह इसी के लिए बना है। हर ब्रांड का अपना डेटाबेस, अपना डोमेन और अपना कंटेंट होता है, इसलिए एक ब्रांड दूसरे का डेटा नहीं पढ़ सकता और एक में हुई कंटेंट की गलती दूसरे में नहीं दिखती। साझा होता है इंजन: रूटिंग, API परत, एडमिन टूल और सुरक्षा का काम।

Cannabivo चालू है: सोशल क्लबों का सर्च इंजन, जहाँ लोग जगह के अनुसार क्लब खोजते और उनकी तुलना करते हैं और क्लब अपनी लिस्टिंग खुद संभालते हैं। Steel इंजीनियरिंग तथा खरीद के लिए सामग्री-समकक्षता का संदर्भ है; यह अभी विकासाधीन है और सार्वजनिक नहीं हुआ है। दोनों उसी प्लेटफ़ॉर्म पर चलते हैं जिसका वर्णन इसी हिस्से में है।

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

कनेक्शन HTTP/3 पर चलते हैं और डोमेन ब्राउज़रों की पहले से लोड HSTS सूची में है — यानी ब्राउज़र पहली ही विज़िट पर बिना एन्क्रिप्शन बात करने से मना कर देता है, इससे पहले कि किसी रीडायरेक्ट को बीच में पकड़ा जा सके। कुंजी विनिमय पोस्ट-क्वांटम है: X25519 के साथ ML-KEM-768। इसे इसलिए चुना गया है कि आज पकड़ा गया ट्रैफ़िक तब भी टिका रहे, जब क्वांटम कंप्यूटर उस पर हमला करने लायक हो जाएँ।

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

हाँ। एप्लिकेशन की घटनाएँ, त्रुटियाँ और प्रशासनिक कार्य सर्वरों पर बिखरी टेक्स्ट फ़ाइलों के बजाय डेटाबेस में लिखे जाते हैं, इसलिए उनमें सचमुच खोजा जा सकता है। प्रशासनिक बदलाव यह दर्ज करते हैं कि किसने किया, क्या बदला और कब। "पिछले महीने यह कीमत किसने बदली" का जवाब होता है, अंदाज़ा नहीं।

ग़ैर-ज़रूरी कुकीज़ तभी सेट होती हैं जब विज़िटर सहमति देता है, यह चुनाव दर्ज होता है, और हमारी बनाई हर साइट पर एक जगह होती है जहाँ बाद में उसे बदला या वापस लिया जा सके। मना करना एक क्लिक है, सेटिंग्स मेन्यू में खोजबीन नहीं — और मना करने वाले को भी पूरी तरह काम करती साइट मिलती है।

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

कंटेंट में। हमारी बहुभाषी सामग्री मॉडल की मदद से बनती और अपडेट होती है, और सार्वजनिक होने से पहले हर भाषा में उसकी समीक्षा होती है — सीधे मॉडल से कभी प्रकाशित नहीं होती। इसीलिए हम AI पर सावधानी से बात करते हैं: अपने ही काम से हमें पता है कि नतीजा कहाँ मज़बूत है और कहाँ अब भी इंसान चाहिए।

कुछ भी बनाने से पहले हम लिखित में बताते हैं कि कौन-सा प्रदाता कौन-सा डेटा संसाधित करेगा और उसमें से क्या रखा जाएगा। यह जवाब आपको ठीक न लगे तो सुविधा दूसरे तरीके से बनती है या बनती ही नहीं। कोई डेटा आपके सिस्टम से उस तरह बाहर नहीं जाता जिस पर आपकी सहमति न हो — और "हमें पता ही नहीं था कि यह भेजा जा रहा है" ऐसा नतीजा है जो हम देना नहीं चाहते।