सॉफ़्टवेयर विकास कंपनी कैसे चुनें?

बुडापेस्ट की सॉफ़्टवेयर विकास कंपनी Mesterséges Intelligencia Központ Kft. के अनुसार अच्छा चुनाव तीन सवालों पर टिका है: क्या डेवलपर लक्ष्य समझता है, क्या उसके प्रस्ताव की जाँच हो सकती है, और हस्तांतरण के बाद कोड और सिस्टम किसका होगा।

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

पहले लक्ष्य: सॉफ़्टवेयर को क्या करना है?

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

• लक्ष्य: सॉफ़्टवेयर कौन-सी समस्या हल करता है, और किससे दिखेगा कि वह सफल है।
• उपयोगकर्ता: आंतरिक कर्मचारी, ग्राहक या साझेदार में से कौन इस्तेमाल करेगा।
• अनिवार्य ज़रूरतें: जिनके बिना इसे शुरू नहीं किया जा सकता, “अच्छा होगा अगर” वाली मदों से अलग।
• मौजूदा सिस्टम: इसे किनसे जुड़ना है (ERP, CRM, वेबशॉप, इनवॉइसिंग, बैंक)।
• डेटा: यह कौन-सा डेटा सँभालता है, व्यक्तिगत डेटा समेत।
• सीमाएँ: क्या कोई तय समय-सीमा, आंतरिक नियम, होस्टिंग या सुरक्षा संबंधी अपेक्षा है।

यह भी तय करना उचित है कि कस्टम विकास की ज़रूरत है भी या नहीं, या कोई रेडीमेड उत्पाद, शायद रेडीमेड उत्पाद और कस्टम विस्तार साथ में, काफ़ी होगा। इसमें कस्टम सॉफ़्टवेयर या रेडीमेड समाधान (SaaS)? लेख मदद करता है।

छोटी सूची: किनसे संपर्क करें?

बहुत सारी कंपनियों से संपर्क करने की ज़रूरत नहीं; कुछ, सोच-समझकर चुने गए उम्मीदवार बहुत सारे सतही प्रस्तावों से बेहतर हैं। छाँटने के मानदंड:

• मिलता-जुलता काम: क्या उसने पहले मिलते-जुलते आकार और प्रकृति का सिस्टम बनाया है, जैसे व्यावसायिक सॉफ़्टवेयर, वेबशॉप, मोबाइल ऐप या AI एकीकरण।
• तकनीकी मेल: क्या वह उन तकनीकों के साथ काम करता है, जिनसे मौजूदा सिस्टमों को जुड़ना है।
• आकार का अनुपात: क्या कंपनी की क्षमता प्रोजेक्ट के अनुरूप है; बड़े सिस्टम के लिए कई विशेषज्ञताएँ चाहिए, छोटे काम के लिए कम।
• भाषा और उपलब्धता: क्या वह आपकी भाषा में, आपके समय-क्षेत्र में बातचीत कर सकता है।

काम और संदर्भों की जाँच

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

अगर कोई पूर्व ग्राहक संदर्भ देता है, तो ठोस सवाल पूछें: क्या तय दायरे का पालन हुआ, बदलाव और बग कैसे सँभाले गए, क्या ग्राहक को सोर्स कोड मिला, और क्या वे अब भी साथ काम करते हैं। सामान्य “हम संतुष्ट थे” कम बताता है; यह बात बहुत बताती है कि ग्राहक हस्तांतरण के बाद भी उन्हीं के साथ सिस्टम चलाता है।

तकनीकी बातचीत

हर उम्मीदवार के साथ एक तकनीकी बातचीत करना उचित है, हो सके तो आपकी ओर से भी किसी तकनीकी विशेषज्ञ की मौजूदगी में। जवाबों का आत्मविश्वास नहीं, बल्कि यह मायने रखता है कि डेवलपर सवाल पूछता है या नहीं, और जोखिमों का नाम लेता है या नहीं। अच्छे सवाल:

• आप इसे कैसे शुरू करेंगे, और पहला चरण क्या होगा?
• आप हमारे मौजूदा सिस्टम कैसे जोड़ेंगे, और आपको उनके बारे में क्या जानना होगा?
• आप परीक्षण कैसे करते हैं, और कौन तय करता है कि कोई हिस्सा तैयार है?
• प्रोजेक्ट पर कौन काम करेगा, और हमारा संपर्क व्यक्ति कौन होगा?
• सिस्टम कहाँ चलेगा, और सुरक्षा अपडेट की ज़िम्मेदारी किसकी होगी?
• अगर इसमें कृत्रिम बुद्धिमत्ता भी होगी: कौन-सा डेटा कहाँ जाएगा, और AI के ग़लती करने पर क्या होगा?

चेतावनी का संकेत है, अगर कोई उम्मीदवार बिना सवाल पूछे, पहली बातचीत के बाद ही सटीक क़ीमत और समय-सीमा बता दे।

प्रक्रिया और संवाद

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

• चरणबद्ध विकास: काम चरणों में बँटा होता है, और हर चरण के अंत में सिर्फ़ रिपोर्ट नहीं, चालू सॉफ़्टवेयर दिखाया जाता है।
• कोड तक पहुँच: ग्राहक पहले दिन से कोड रिपॉज़िटरी (repository) देख सकता है, उसे सिर्फ़ हस्तांतरण के समय नहीं पाता।
• पारदर्शी कार्य-सूची: काम, बग और बदलाव एक साझा सूची में दिखते हैं।
• स्थायी संपर्क व्यक्ति: एक व्यक्ति, जो प्रोजेक्ट को जानता है और निर्णय ले सकता है।
• बदलाव प्रबंधन: नई या बदली हुई ज़रूरत लिखी जाती है, मापी या अनुमानित की जाती है, और स्वीकृति के बाद ही काम में आती है।

प्रस्तावों की तुलना

दो प्रस्तावों की तुलना तभी हो सकती है, जब वे एक ही दायरे के लिए हों। इसलिए हर उम्मीदवार को एक ही मद-दर-मद विवरण मिले, और उनसे पूछें कि क़ीमत किन फ़ंक्शनों और कितने आकार के लिए दी गई है। अगर डेवलपर सॉफ़्टवेयर का कार्यात्मक आकार किसी मानक पद्धति से (जैसे COSMIC फ़ंक्शन पॉइंट में) मापता है, तो आकार उसी विनिर्देश से जाँचा जा सकता है; पद्धति को COSMIC फ़ंक्शन पॉइंट क्या है? लेख समझाता है।

अगर दो प्रस्तावों में बड़ा अंतर है, तो ये सवाल पूछना उचित है:

सवाल	इससे क्या पता चलता है
क़ीमत कितने आकार और किन फ़ंक्शनों के लिए है?	क्या एक ही दायरे की क़ीमत दी गई
अलग मद के रूप में क्या है?	क्या एकीकरण, डेटा स्थानांतरण, ग्राफ़िक्स, संचालन शामिल हैं
किन ग़ैर-कार्यात्मक आवश्यकताओं को ध्यान में रखा गया?	प्रदर्शन, सुरक्षा, सुलभता
बदलाव कैसे सँभाले जाते हैं?	काम के दौरान नई ज़रूरत आने पर क्या होता है
हस्तांतरण के बाद बग सुधार की व्यवस्था क्या है?	शुल्क में क्या शामिल है, और क्या अलग काम गिना जाता है
सोर्स कोड किसका होगा, और हमें कौन-से अधिकार मिलेंगे?	क्या सिस्टम को कोई और आगे ले जा सकता है
बिलिंग तय क़ीमत पर है या प्रयास के आधार पर?	दायरे का जोखिम कौन उठाता है

तय क़ीमत तब अच्छी चलती है, जब दायरा मद-दर-मद तय हो; प्रयास-आधारित बिलिंग ज़्यादा लचीली है, पर दायरे का जोखिम ग्राहक के पास रहता है। दोनों मामलों में मायने यह रखता है कि दायरा मापा और ट्रैक किया जा सके। हम क़ीमत कैसे तय करते हैं, यह मूल्य निर्धारण पृष्ठ बताता है।

अनुबंध की मुख्य बातें

विवाद या अप्रत्याशित स्थिति में अनुबंध ही मायने रखता है। नीचे की बातें जानकारी हैं, क़ानूनी सलाह नहीं: अनुबंध किसी वकील से भी जँचवाना उचित है।

सोर्स कोड और उपयोग के अधिकार

हंगरी का कॉपीराइट क़ानून (1999 का अधिनियम LXXVI, Szjt., हंगेरियन में) कंप्यूटर प्रोग्राम को, सोर्स कोड और ऑब्जेक्ट कोड दोनों रूपों में, लेखकीय कृति के रूप में संरक्षित करता है (धारा 1(2)(c)), और कहता है कि सॉफ़्टवेयर से जुड़े आर्थिक अधिकार हस्तांतरणीय हैं (धारा 58(3))। इसलिए ग्राहक या तो आर्थिक अधिकार प्राप्त करता है, या उपयोग की अनुमति (लाइसेंस) पाता है; दोनों एक बात नहीं हैं।

कुछ नियम, जिनकी वजह से सटीक शब्दावली अहम है: उपयोग अनुबंध अनन्य अधिकार सिर्फ़ स्पष्ट शर्त होने पर देता है (धारा 43(1)); अगर अनुबंध उपयोग के तरीक़े और सीमा नहीं बताता, तो अनुमति अनुबंध के उद्देश्य के लिए अनिवार्य रूप से ज़रूरी सीमा तक सीमित रहती है (धारा 43(5)); अगर विषय-वस्तु अस्पष्ट हो, तो लेखक के लिए ज़्यादा अनुकूल व्याख्या माननी होती है (धारा 42(3)); और उपयोगकर्ता किसी तीसरे पक्ष को अनुमति सिर्फ़ लेखक की स्पष्ट सहमति से दे सकता है (धारा 46(1))। इसलिए यह तय करना उचित है:

• पूरे सोर्स कोड और दस्तावेज़ीकरण का हस्तांतरण, चरण-दर-चरण भी;
• कि ग्राहक आर्थिक अधिकार प्राप्त करता है, या उसे किस सीमा की अनुमति मिलती है (अनन्य है या नहीं, बदली जा सकती है या नहीं, आगे दी जा सकती है या नहीं);
• कि डेवलपर के पास उसके कर्मचारियों और उप-ठेकेदारों द्वारा लिखे कोड के अधिकार हैं;
• इस्तेमाल किए गए ओपन-सोर्स और तीसरे पक्ष के घटकों की सूची और उनके लाइसेंस।

गोपनीयता (NDA)

अगर विचार या व्यावसायिक डेटा गोपनीय है, तो विवरण साझा करने से पहले गोपनीयता समझौता (NDA) करना उचित है। उसमें तय करें कि गोपनीय जानकारी क्या है, कौन उसे जान सकता है, गोपनीयता कब तक रहती है, और काम के अंत में सामग्री का क्या होता है।

बग सुधार और वारंटी

अनुबंध बताए कि बग क्या है (तय आवश्यकता से विचलन), स्वीकृति परीक्षण कैसे होता है, कौन-से गंभीरता स्तर हैं, और डेवलपर किस स्तर पर कितनी जल्दी प्रतिक्रिया देता है। यह भी तय करें कि हस्तांतरण के समय छिपे रहे दोष वह कितने समय तक निःशुल्क ठीक करता है, और क्या पहले से आगे का विकास गिना जाता है।

संचालन और SLA

अगर डेवलपर हस्तांतरण के बाद भी सिस्टम चलाता है, तो सेवा स्तर समझौता (service level agreement, SLA) शर्तें तय करता है: वादा की गई उपलब्धता, त्रुटि की सूचना देने का तरीक़ा, गंभीरता के अनुसार प्रतिक्रिया और सुधार का समय, रखरखाव की समय-खिड़कियाँ, बैकअप और रिपोर्टिंग। जो लिखा नहीं है, उसकी विवाद में माँग नहीं की जा सकती।

निकास योजना

निकास योजना इस सवाल का जवाब देती है कि डेवलपर के साथ काम आगे न चले, तो क्या होगा, चाहे असंतोष के कारण, चाहे डेवलपर के बंद हो जाने के कारण। इसके तत्व:

• इंस्टॉलेशन, आर्किटेक्चर और संचालन का अद्यतन दस्तावेज़ीकरण;
• कोड रिपॉज़िटरी, होस्टिंग, डोमेन और क्लाउड अकाउंट ग्राहक के नाम पर, या कम से कम ग्राहक की पहुँच के साथ;
• पासवर्ड और एक्सेस कुंजियों के हस्तांतरण की व्यवस्था;
• मानक फ़ॉर्मेट में डेटा का एक्सपोर्ट;
• नए डेवलपर को हस्तांतरण में सहयोग।

डेटा संरक्षण: डेटा प्रसंस्करण समझौता

अगर काम के दौरान डेवलपर व्यक्तिगत डेटा तक पहुँचता है (जैसे सिस्टम चलाता है या लाइव डेटा से परीक्षण करता है), तो GDPR के अनुसार वह आमतौर पर डेटा प्रसंस्करणकर्ता माना जाता है, और उसके साथ लिखित डेटा प्रसंस्करण समझौता चाहिए (GDPR अनुच्छेद 28)। इसमें अन्य बातों के अलावा तय होना चाहिए कि वह डेटा सिर्फ़ ग्राहक के प्रलेखित निर्देशों पर संसाधित करता है, गोपनीयता और सुरक्षा सुनिश्चित करता है, दूसरा प्रसंस्करणकर्ता सिर्फ़ अनुमति से लगाता है, सेवा के अंत में डेटा मिटाता या लौटाता है, और ऑडिट की अनुमति देता है।

सुरक्षा व्यवहार

सुरक्षा को सॉफ़्टवेयर में बाद में नहीं जोड़ा जा सकता, इसलिए पूछना उचित है कि डेवलपर इस पर कैसे काम करता है। अच्छा शुरुआती बिंदु OWASP Top 10 है, वेब ऐप्लिकेशनों के सबसे गंभीर सुरक्षा जोखिमों की व्यापक रूप से जानी जाने वाली सूची; वर्तमान संस्करण OWASP Top 10:2025 है (17 अक्टूबर 2026 को जाँचा गया)। पहले तीन स्थानों पर दोषपूर्ण एक्सेस नियंत्रण, ग़लत सुरक्षा कॉन्फ़िगरेशन और सॉफ़्टवेयर आपूर्ति शृंखला की विफलताएँ हैं। पूछें:

• आप अनुमतियाँ कैसे सँभालते हैं, और कैसे परखते हैं कि उपयोगकर्ता सिर्फ़ अपना डेटा देखे?
• आप इस्तेमाल की गई बाहरी लाइब्रेरी कैसे अपडेट करते हैं, और आपको कैसे पता चलता है कि उनमें से कोई असुरक्षित है?
• आप पासवर्ड और कुंजियाँ कहाँ रखते हैं, और उन तक किसकी पहुँच है?
• क्या कोड समीक्षा (code review) और स्वचालित परीक्षण होते हैं?
• बैकअप कैसे बनता है, और क्या आपने कभी उसे बहाल करके देखा है?

फ़्रीलांसर या विकास कंपनी?

दोनों अच्छा विकल्प हो सकते हैं; सवाल यह है कि काम कितना बड़ा है और सिस्टम कितने लंबे समय तक चलेगा।

पहलू	फ़्रीलांसर	विकास कंपनी
संवाद	सीधा, एक व्यक्ति से	संपर्क व्यक्ति के ज़रिए, कई विशेषज्ञों के साथ
विशेषज्ञताएँ	एक व्यक्ति का ज्ञान	कई विशेषज्ञताएँ: इंटरफ़ेस, बैकएंड, मोबाइल, संचालन, परीक्षण
प्रतिस्थापन की संभावना	बीमारी या छोड़कर जाने पर काम रुक जाता है	टीम एक-दूसरे का काम सँभाल सकती है
क्षमता	छोटे, स्पष्ट रूप से सीमित कामों के लिए	बड़े सिस्टमों, समानांतर काम के लिए
अनुबंध	सीधे विशेषज्ञ से	कंपनी से, जो टीम के काम के लिए ज़िम्मेदार है
दीर्घकालिक संचालन	फ़्रीलांसर की उपलब्धता पर निर्भर	संगठित रूप से लिया जा सकता है

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

चेतावनी के संकेत

• पहली बातचीत के बाद ही, बिना सवालों के, सटीक क़ीमत और समय-सीमा।
• कोई लिखित विनिर्देश नहीं, या प्रस्ताव यह नहीं बताता कि वह किसके लिए है।
• ग्राहक कोड नहीं देख सकता, उसे सिर्फ़ हस्तांतरण के समय मिलेगा।
• प्रोजेक्ट पर कौन काम करेगा, इस पर अस्पष्ट जवाब।
• साफ़ नहीं कि सोर्स कोड किसका होगा, और ग्राहक को कौन-से अधिकार मिलेंगे।
• डेटा प्रसंस्करण समझौते या गोपनीयता समझौते से इनकार।
• दिखाने लायक कोई चालू काम नहीं।

जाँच-सूची

सवाल	ठीक है, अगर
क्या लक्ष्य और अनिवार्य ज़रूरतें लिखी गई हैं?	एक छोटा विवरण है, जिसे सब एक जैसा समझते हैं
क्या हमने चालू काम देखा?	हमने कम से कम एक मिलता-जुलता सिस्टम आज़माया
क्या वे काम समझते हैं?	उन्होंने सवाल पूछे और जोखिमों का नाम लिया
क्या हम प्रगति देखेंगे?	चरणबद्ध डेमो, कोड रिपॉज़िटरी तक पहुँच
क्या प्रस्ताव की तुलना हो सकती है?	वह एक ही मद-दर-मद दायरे के लिए है, अलग मदें दिखती हैं
क्या सोर्स कोड और अधिकारों का सवाल सुलझा है?	अनुबंध हस्तांतरण और अधिकारों की सीमा बताता है
क्या गोपनीयता और डेटा प्रसंस्करण समझौता है?	जहाँ ज़रूरी, हस्ताक्षरित
क्या बग सुधार और संचालन तय है?	गंभीरता स्तर, प्रतिक्रिया समय, SLA
क्या निकास योजना है?	दस्तावेज़ीकरण, पहुँच, डेटा एक्सपोर्ट
क्या हमने सुरक्षा के बारे में पूछा?	अनुमतियों, अपडेट और बैकअप पर ठोस जवाब

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

फ़्रीलांसर या विकास कंपनी?

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

दो प्रस्तावों की तुलना कैसे करें?

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

अनुबंध में क्या होना चाहिए?

दायरा (मद-दर-मद विनिर्देश), क़ीमत और समय-सारिणी, सोर्स कोड का हस्तांतरण और उपयोग के अधिकारों की सीमा, गोपनीयता, स्वीकृति और बग सुधार की व्यवस्था, संचालन और SLA, निकास योजना, और अगर व्यक्तिगत डेटा भी शामिल है, तो डेटा प्रसंस्करण समझौता। यह जानकारी है, क़ानूनी सलाह नहीं।

अगर डेवलपर ग़ायब हो जाए, तो क्या होगा?

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

सोर्स कोड किसका होगा?

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

हम कैसे मदद करते हैं?

हम ऐसे काम करते हैं: पहला परामर्श निःशुल्क है, विनिर्देश हम मिलकर लिखते हैं, सॉफ़्टवेयर का आकार COSMIC फ़ंक्शन पॉइंट में मापते हैं, और इसी से प्रस्ताव और समय-सारिणी बनती है। विकास चरणों में आगे बढ़ता है, हर चरण के अंत में डेमो के साथ; अनुरोध पर हम गोपनीयता समझौता (NDA) करते हैं, और हस्तांतरण के बाद हम संचालन और रखरखाव की ज़िम्मेदारी भी लेते हैं। सोर्स कोड और उपयोग के अधिकार अनुबंध में तय होते हैं। क़दम हम कैसे काम करते हैं पृष्ठ पर, और मूल्य निर्धारण की पद्धति मूल्य निर्धारण पृष्ठ पर लिखी है।

फ़िलहाल हम एक बड़ा ERP और CRM सिस्टम विकसित कर रहे हैं; अपने, आज़माए जा सकने वाले प्रोजेक्ट हम हमारा काम पृष्ठ पर दिखाते हैं, कंपनी के बारे में हमारे बारे में पृष्ठ पर, और आम सवालों के जवाब अक्सर पूछे जाने वाले प्रश्न पृष्ठ पर पढ़ सकते हैं। अगर आप डेवलपर खोज रहे हैं, तो संपर्क पृष्ठ पर दिए गए विवरणों पर हमें लिखें।

स्रोत

• Nemzeti Jogszabálytár (हंगरी का राष्ट्रीय क़ानून डेटाबेस): कॉपीराइट पर 1999 का अधिनियम LXXVI (हंगेरियन में)
• EUR-Lex: विनियमन (EU) 2016/679 (सामान्य डेटा संरक्षण विनियमन, GDPR)
• OWASP: OWASP Top 10
• OWASP: OWASP Top 10:2025