< BACK 2026 में कस्टम सॉफ्टवेयर की लागत कैसे निकालें: संस्थापकों के लिए एक व्यावहारिक अनुमानक -- लाइन-आर्ट इलस्ट्रेशन

2026 में कस्टम सॉफ्टवेयर की लागत कैसे निकालें: फाउंडर्स के लिए एक काम का अनुमानक

एक फाउंडर ने मुझे नवंबर 2024 में फोन किया, क्रिसमस से दो हफ्ते पहले, बिल्कुल गुस्से में। एक वेब एजेंसी ने उसे एक कस्टम लॉजिस्टिक्स डैशबोर्ड के लिए £14,000 का कोटेशन दिया था। उसने साइन कर दिया। छह महीने बाद आखिरी इनवॉइस £61,000 पर आ गया। टेक्निकली किसी ने उससे झूठ नहीं बोला था। लेकिन किसी ने उसे सच भी नहीं बताया, क्योंकि किसी ने भी उसका पैसा लेने से पहले सही तरीके से एस्टीमेट करने का काम नहीं किया था।

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

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

तो। यह फ्रेमवर्क है जो मैं असल में इस्तेमाल करता हूँ। खाली सेल्स वाली स्प्रेडशीट टेम्पलेट नहीं। एक असली मानसिक मॉडल, वर्तमान 2026 के नंबर्स के साथ, विशिष्ट टूल्स, और वह सावधानियाँ जो महत्वपूर्ण हैं।

---

ज्यादातर सॉफ्टवेयर कोट्स कल्पना क्यों हैं

समस्या बेईमानी नहीं है (आमतौर पर)। यह है कि सॉफ़्टवेयर एस्टीमेशन सच में मुश्किल है, और ज़्यादातर लोग यह कम आँकते हैं कि वह कितना मुश्किल है, इसलिए वे ऐसे शॉर्टकट के लिए जाते हैं जो कठोरता जैसे लगते हैं लेकिन नहीं हैं।

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

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

Uncertainty की Cone वास्तविक है

Cone of uncertainty, Steve McConnell द्वारा लोकप्रिय, बताता है कि project estimates कैसे अधिक सटीक हो जाते हैं जैसे-जैसे आप delivery के करीब आते हैं। ideation में, आप किसी भी दिशा में 4x से हट सकते हैं। विस्तृत डिज़ाइन के बाद, शायद 1.25x। अधिकांश founders ideation स्तर पर quotes ले रहे हैं और उन्हें हस्ताक्षरित अनुबंध की तरह मान रहे हैं।

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

---

चार वास्तविक लागत बाल्टियाँ

किसी भी एस्टीमेटर के काम कर सकने से पहले, आपको प्रोजेक्ट को सही कैटेगरीज़ में विभाजित करना होगा। "फ्रंटएंड, बैकएंड, QA" नहीं, वे रोल हैं, लागत चालक नहीं। असली बकेट्स ये हैं:

1. Greenfield vs. Integration Work

Greenfield, कुछ ऐसा बनाना जो स्क्रैच से है आपके खुद के डेटाबेस और बिज़नेस लॉजिक के विरुद्ध, लगभग हर प्रोजेक्ट का सस्ता, ज़्यादा प्रेडिक्टेबल आधा है। यह इंटीग्रेशन का काम है जो आपको पकड़ता है। हर बाहरी API, लीगेसी सिस्टम, पेमेंट प्रोसेसर, या थर्ड-पार्टी ऑथ प्रोवाइडर नॉन-लीनियर जटिलता जोड़ता है। मैं आमतौर पर किसी भी स्कोप लाइन पर 30-40% कंटिंजेंसी जोड़ता हूँ जो बाहरी सिस्टम को छूती है।

2. UI/UX डिज़ाइन (इस लाइन को छोड़ें मत)

बहुत सारे फाउंडर्स डिज़ाइन को ऑप्शनल मानते हैं या इसे डेवलपमेंट एस्टीमेट में रोल करने की कोशिश करते हैं। गलती। डिज़ाइन सही तरीके से किया गया, वायरफ्रेम्स, Figma में इंटरएक्टिव प्रोटोटाइप, एक टेस्टेड कंपोनेंट लाइब्रेरी, आमतौर पर कुल प्रोजेक्ट लागत का 15-25% चलता है। इसे छोड़ दो और आप दो बार भुगतान करोगे: एक बार डेवलपर रीवर्क में जब आवश्यकताएँ अस्पष्ट निकलती हैं, और फिर से यूजर रिसर्च में बाद में जब प्रोडक्ट कन्वर्ट नहीं करता।

3. इंफ्रास्ट्रक्चर और DevOps

कोई इसे सही तरीके से उद्धृत नहीं करता। स्टेजिंग एनवायरनमेंट्स, CI/CD पाइपलाइन्स (हम अब लगभग सब कुछ के लिए GitHub Actions इस्तेमाल करते हैं), Docker के साथ कंटेनराइजेशन, AWS या GCP पर क्लाउड होस्टिंग, ये असली खर्च हैं जो नहीं गायब होते क्योंकि किसी ने उन्हें रेखांकित नहीं किया। मध्यम-जटिलता वाले SaaS के लिए, शुरुआती इन्फ्रास्ट्रक्चर सेटअप के लिए कम से कम £3,000-£6,000 का बजट रखें, और साथ ही चल रहे मासिक खर्च जो आम तौर पर £200-£800 के बीच चलते हैं, उपयोग के आधार पर।

4. टेस्टिंग, QA और लॉन्च ओवरहेड

स्वचालित परीक्षण सुइट्स, मैनुअल QA पास, परफॉर्मेंस टेस्टिंग, भुगतान या व्यक्तिगत डेटा संभालने वाली किसी भी चीज़ के लिए सुरक्षा समीक्षा, यह सही तरीके से किए जाने पर कुल विकास समय का आमतौर पर 20% होता है। अधिकांश एजेंसी कोट्स में "परीक्षण" एक लाइन आइटम के रूप में शामिल होता है और इसका मतलब "एक dev हस्तांतरण कॉल से पहले एक दोपहर के लिए आस-पास क्लिक किया।"

---

एक काम करने वाला एस्टिमेटर: मॉड्यूल मेथड

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

चरण 1: प्रत्येक फीचर को यूजर स्टोरी के रूप में सूचीबद्ध करें। "यूजर मैनेजमेंट" नहीं, यह बहुत अस्पष्ट है। "एक यूजर ईमेल और पासवर्ड के साथ पंजीकृत हो सकता है, अपना ईमेल सत्यापित कर सकता है, अपना पासवर्ड रीसेट कर सकता है, और अपनी प्रोफाइल फोटो अपडेट कर सकता है।" चार स्टोरी। प्रत्येक का एक खर्च है।

Step 2: हर story को complexity के आधार पर rate करें। मैं तीन tiers का उपयोग करता हूँ:

  • Simple (S): शुद्ध CRUD, कोई external dependencies नहीं, standard UI patterns। सोचिए: एक settings page, एक profile update form, एक data table with sorting।
  • Medium (M): कुछ business logic, एक external integration, या non-standard UI। सोचिए: एक filtered search with saved queries, एक webhook handler, एक Stripe subscription flow।
  • Complex (C): कई integrations, real-time features, algorithmic logic, या भारी infrastructure। सोचिए: एक live chat system, एक recommendation engine, एक multi-tenant permission model।

स्टेप 3: पॉइंट एस्टिमेट नहीं, घंटों की रेंज असाइन करें।

2026 में, एक मिड-टियर UK एजेंसी या एक मजबूत nearshore टीम के साथ काम करते हुए, यहाँ मेरा बजट है:

  1. सरल स्टोरी: 4-8 घंटे
  2. मध्यम स्टोरी: 12-24 घंटे
  3. जटिल स्टोरी: 30-80 घंटे (हाँ, वह चौड़ा, जटिल सच में अप्रत्याशित है)

चरण 4: अपनी दर लागू करें।

वर्तमान बाजार दरें जिन्हें जानना जरूरी है:

  • लंदन स्थित सीनियर डेवलपर (फ्रीलांस): £90-£140/घंटा
  • UK एजेंसी (पूरी टीम, प्रोजेक्ट प्रबंधित): £80-£120/घंटा ब्लेंडेड
  • मजबूत निकटस्थ क्षेत्र (पूर्वी यूरोप, LatAm): £35-£65/घंटा
  • ऑफशोर (दक्षिण एशिया, फिलीपींस): £15-£35/घंटा, और हाँ, आप यहाँ उत्कृष्ट काम पा सकते हैं, लेकिन संचार ओवरहेड असली है और इसे मूल्य में शामिल करने की आवश्यकता है

चरण 5: ओवरहेड को स्पष्ट रूप से जोड़ें।

इन्हें अवशोषित न करें। उन्हें लाइन-आइटम करें:

  • प्रोजेक्ट प्रबंधन: डेव घंटों का 10-15%
  • डिजाइन (यदि पहले से स्कोप नहीं किया गया है): कुल का 15-25%
  • DevOps/इंफ्रास्ट्रक्चर सेटअप: जटिलता के आधार पर £3,000-£8,000 निर्धारित
  • QA: विकास घंटों का न्यूनतम 20%
  • आकस्मिक खर्च: ग्रीनफील्ड कार्य पर 20%, महत्वपूर्ण इंटीग्रेशन वाली किसी भी चीज़ पर 35%

---

एक वास्तविक उदाहरण: SaaS Dashboard, 2026 मूल्य निर्धारण

मुझे कुछ ठोस के माध्यम से चलने दो। एक संस्थापक मेरे पास एक B2B विश्लेषण डैशबोर्ड चाहते हुए आता है, एक SaaS उत्पाद जहाँ उनके क्लाइंट्स लॉगिन करते हैं, अपना परफॉर्मेंस डेटा देखते हैं जो Google Analytics 4 और एक कस्टम इवेंट डेटाबेस से खींचा गया है, रिपोर्ट्स निर्यात कर सकते हैं, और अपनी टीम की एक्सेस को प्रबंधित कर सकते हैं।

मैं इसे कैसे तोड़ूँ:

  • Auth system (email + Google SSO, role-based access):2 Medium stories = 48 hrs
  • GA4 integration + data pipeline:1 Complex story = 55 hrs
  • Custom event database schema + API:2 Medium stories = 40 hrs
  • Dashboard UI (charts via Chart.js or Recharts, responsive):3 Medium stories = 65 hrs
  • Report export to PDF/CSV:1 Medium story = 18 hrs
  • Team management (invite, remove, role assignment):2 Simple + 1 Medium stories = 28 hrs
  • Billing via Stripe (subscriptions, upgrade/downgrade):1 Complex story = 45 hrs

Raw development total: ~299 hours

£95/hr की UK agency दर लागू करें:£28,405

Add:

  • Design (20%): £5,681
  • DevOps setup: £4,500
  • QA (20% of dev hours, same rate): £5,681
  • PM (12%): £3,409
  • Integration contingency (30% on GA4 and Stripe work): £3,000

Total estimate: ~£50,676

यह एक वास्तविक संख्या है एक वास्तविक उत्पाद के लिए। बिल्कुल चौंकाने वाली नहीं है अगर आप समझते हैं कि इसमें क्या है। पूरी तरह चौंकाने वाली है अगर आप £18,000 की उम्मीद लेकर आए हैं क्योंकि किसी ने आपके नेटवर्क में किसी संस्थापक को पिछले साल "कुछ इसी तरह" के लिए यही कहा था।

---

छिपी हुई लागतें जिनका कोई जिक्र नहीं करता

लाइसेंस और तीसरे पक्ष की सेवाएं

मैपिंग फीचर्स के लिए Mapbox। SMS के लिए Twilio। ट्रांजैक्शनल ईमेल के लिए SendGrid। अगर आपको सही सर्च की जरूरत है तो Algolia। ये चल रही लागतें हैं जिन्हें संस्थापक अपने सॉफ्टवेयर बजट से पूरी तरह छोड़ देते हैं क्योंकि वे इन्हें "सिर्फ APIs" मानते हैं। 10,000 सक्रिय उपयोगकर्ताओं वाला एक मध्य-स्तरीय SaaS हो सकता है कि तीसरे पक्ष की सेवाओं में £800-£2,000/माह का भुगतान कर रहा हो इससे पहले कि एक भी सर्वर बिल आए।

सुरक्षा और अनुपालन

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

हस्तांतरण और प्रलेखन

अच्छी डॉक्यूमेंटेशन, API docs, deployment runbooks, भविष्य के devs के लिए ऑनबोर्डिंग गाइड्स, असली समय खर्च करते हैं। डॉक्यूमेंटेशन के लिए कुल प्रोजेक्ट घंटों का 5-8% बजट करें यदि आप कभी चीज़ को बनाए रखने, विस्तारित करने, या बेचने में सक्षम होना चाहते हैं।

---

आप जो उद्धरण प्राप्त कर रहे हैं उसे दबाव-परीक्षण कैसे करें

आपके सामने एक प्रस्ताव है। यहाँ हस्ताक्षर करने से पहले इसे ऑडिट करने का तरीका है:

  1. संख्या के पीछे की फीचर ब्रेकडाउन माँगें। अगर वे आपको स्टोरी-लेवल ब्रेकडाउन नहीं दे सकते, तो उद्धरण एक अनुमान है।
  2. जाँचें कि DevOps, QA और PM लाइन आइटम हैं या एक मिश्रित दर में छिपे हुए हैं। छिपा हुआ आमतौर पर कम पकाया हुआ मतलब है।
  3. पूछें कि उनकी आकस्मिकता नीति क्या है। क्या वे ओवररन को सीमित करते हैं? टाइम-एंड-मेटेरियल्स या फिक्स्ड प्राइस? प्रत्येक के वास्तविक निहितार्थ हैं।
  4. पता लगाएं कि उन्होंने तीसरे पक्ष के एकीकरण के बारे में कौन सी मान्यताएं बनाई हैं। उनसे सीधे पूछें: "क्या आपने [विशिष्ट सेवा] के लिए API प्रलेखन को उद्धरण देने से पहले पढ़ा है?"
  5. पूछें कि स्प्रिंट 2 के बाद आवश्यकताएं बदल जाएं तो क्या होता है। जवाब आपको एजेंसी कैसे काम करती है इसके बारे में लगभग सब कुछ बताता है।

Basecamp की Shape Up पद्धति के पास इसके लिए एक वास्तव में उपयोगी फ्रेमिंग है: निश्चित समय, परिवर्तनशील स्कोप। किसी भी एजेंसी वार्ता में जाने से पहले इसे पढ़ने लायक है।

---

2026 में AI Tools: वे क्या बदलते हैं (और क्या नहीं)

सभी जानना चाहते हैं कि क्या GitHub Copilot, Cursor, या agent-based coding tools की नई लहर (Devin, Replit Agent) ने सॉफ्टवेयर की लागत में महत्वपूर्ण कमी लाई है। ईमानदारी से? हाँ, थोड़ी है। लेकिन hype सुझाता है उससे कम।

मेरा कच्चा अनुभव: मजबूत AI-सहायक डेवलपर्स ग्रीनफील्ड CRUD काम पर लगभग 20-30% तेजी से काम कर रहे हैं। मानक फीचर्स का वह मध्य भाग, फॉर्म्स, टेबल्स, बेसिक ऑथ फ्लोज़, वास्तव में तेजी से आता है। लेकिन जटिल इंटीग्रेशन काम, आर्किटेक्चरल निर्णय, सूक्ष्म रेस कंडीशन्स को डीबग करना, और कुछ भी जिसके लिए गहरी प्रोडक्ट सोच की आवश्यकता हो? AI वहाँ मदद नहीं करता, और कुछ मामलों में यह विश्वसनीय दिखने वाला कोड उत्पन्न करता है जो नई समस्याएं पेश करता है।

अगर टीम की पुष्टि है कि वह 2026 में गंभीरता से AI टूलिंग का उपयोग कर रही है तो मैं साधारण और मध्यम स्टोरीज पर 10-15% दक्षता छूट लागू करूँगा। उससे अधिक नहीं। कोई भी आपको 50% कम खर्च में "क्योंकि हम AI का उपयोग करते हैं" बताना वास्तव में या तो एक बिल्कुल अलग तरह का प्रोजेक्ट चला रहा है जितना आप सोचते हैं, या आपको कुछ बहुत अच्छा बता रहा है।

---

FAQ

सॉफ्टवेयर estimate कितना सटीक हो सकता है specs लिखे जाने से पहले?

बहुत नहीं। आइडिया स्टेज पर ±40-60% भिन्नता की उम्मीद करें। एक बार जब आपके पास विस्तृत यूजर फ्लोज़, एक डेटा मॉडल, और सभी तीसरे पक्ष की निर्भरताओं की एक सूची है, तो आप ±20% तक जा सकते हैं। वायरफ्रेम्स और तकनीकी आर्किटेक्चर के साथ एक खोज स्प्रिंट के बाद: ±10-15%। एक पूर्ण बिल्ड बजट पर प्रतिबद्ध होने से पहले एक उचित खोज एनगेजमेंट के लिए भुगतान करें, यह आमतौर पर £2,000-£6,000 की लागत होती है और प्रोजेक्ट पर आप जो सबसे अच्छा पैसा खर्च करेंगे वह है।

क्या मुझे fixed-price लेना चाहिए या time-and-materials?

निश्चित मूल्य आपको बजट निश्चितता देता है लेकिन जोखिम को एजेंसी पर स्थानांतरित करता है, जिसका मतलब है कि वे अनुमान को पैड करेंगे और चेंज-ऑर्डर क्लॉज़ के साथ खुद को सुरक्षित करेंगे। समय-और-सामग्री ईमानदार है लेकिन आपको सक्रिय रूप से स्कोप को प्रबंधित करने की आवश्यकता है। अधिकांश संस्थापकों के लिए मेरी पसंद: प्रति स्प्रिंट निश्चित मूल्य (आमतौर पर 2 सप्ताह), प्रत्येक स्प्रिंट की शुरुआत में स्कोप परिभाषित के साथ। आप पैडिंग गेम के बिना भविष्यवाणीयोग्यता प्राप्त करते हैं।

क्या nearshore या offshore development, management overhead को factor करने के बाद, सच में सस्ता है?

अक्सर हाँ, लेकिन हमेशा नहीं। ओवरहेड असली है—ज्यादा PM समय, ज्यादा async कम्यूनिकेशन, expectations के मिसअलाइन होने से कभी-कभी दोबारा काम। अच्छी तरह scope किए गए प्रोजेक्ट के लिए, strong specs के साथ, nearshore (खासतौर पर Eastern Europe) असली value देता है। मैंने पोलिश और यूक्रेनी टीमों के साथ £40/hr blended rate पर सफल प्रोजेक्ट चलाए हैं। कुछ ambiguous और fast-moving के लिए, मैं इसे घर के करीब रखूँ।

Software proposal में red flag क्या होता है?

एक single-line quote बिना breakdown के। एक timeline जिसमें QA या deployment शामिल नहीं। change requests को कैसे हैंडल किया जाता है इसका कोई जिक्र नहीं। और सच कहूँ तो, कोई भी agency जो आपके existing infrastructure के बारे में quote से पहले आपसे कठोर सवाल नहीं पूछती। अगर वे आपकी constraints के बारे में curious नहीं हैं, तो उन्होंने आपके प्रोजेक्ट के बारे में गंभीरता से सोचा ही नहीं।

Post-launch maintenance के लिए बजट कैसे करूं?

Standard rule: initial build cost का 15-20% हर साल ongoing maintenance, bug fixes, और minor feature work के लिए। एक £50,000 build को £7,500-£10,000 annual maintenance budget की जरूरत है। अगर कोई आपसे कहे कि software launch पर "done" है, तो अलग software people ढूंढ लीजिए।

---

November का वह logistics founder? वह अपनी agency के पास गया, उन्होंने अपनी working process को refactor किया, और product March में ship हुआ। यह अच्छे से चल रहा है। लेकिन उसने मुझे बताया कि वह चाहता था कि किसी ने उसे ऐसा framework दे दिया होता जैसे यह कुछ और sign करने से पहले। तो। वहां यह है।

संबंधित पाठ: Next.js और Supabase के साथ रीयल-टाइम नीलामी साइट बनाना, कस्टम वेब विकास, और कस्टम सॉफ़्टवेयर।

< BACK