SaaS, Custom या Self-Hosted? पहली Invoice से आगे की Software Guide

मेज़ पर तीन proposals हैं: monthly subscription, custom build और self-hosted licence। पहली invoice से एक सस्ता लगता है। लेकिन दो साल बाद payroll run अटक जाए तो कौन ठीक करेगा? यह समझाने का उदाहरण है, किसी ग्राहक की case study नहीं।

फ़ैसला सिर्फ़ “किराये पर लें, बनाएँ या मालिक बनें” नहीं है। Hosting, billing, implementation और intellectual-property rights अलग बातें हैं। Self-hosted product में annual subscription हो सकता है; custom app में paid services और third-party licences भी। वास्तविक terms और responsibilities की तुलना करें।

यह 2026 के लिए संतुलित framework है: ज़रूरी workflows साबित करें, तय अवधि की पूरी लागत निकालें और छोड़कर जाने का रास्ता जाँचें। StoreConsole self-hosted product बेचता है, इसलिए commercial interest स्पष्ट है। Framework में SaaS या custom बेहतर हो तो उसे चुनना भी संभव होना चाहिए।

तीनों मॉडल, आसान शब्दों में

सवाल	SaaS	Custom build	Self-hosted licence
क्या खरीदते हैं	Provider चलाने वाली service का access	Development और agreed rights/deliverables	Product licence और deployment rights
कौन चलाता है	Provider के काम, साथ में अपनी configuration/access duties	Agreement के अनुसार आप, partner या managed services	आप या partner; contract के अनुसार vendor support
क्या जाँचें	Usage terms, access, export और recovery	Scope, IP/licences, maintenance और handover	Licence limits, support, operations और exit

असली मायने रखने वाली लागत: पाँच साल की TCO

Total cost of ownership यानी TCO में implementation, migration, training, licence, hosting, integration, support और internal work जोड़ें। जहाँ ज़रूरी हो change, recovery और exit costs रखें। पाँच साल यहाँ comparison window है, हर system की तय उम्र नहीं। सभी options में scope, service level और accounting basis बराबर रखें।

समान scope का एक सरल cost example

नीचे के currency-unit आँकड़े जानबूझकर बनाए गए उदाहरण हैं, vendor quote, market average या StoreConsole की कीमत नहीं। Monthly allowance में संबंधित services और internal labour शामिल हैं। सरल base case में usage और prices स्थिर हैं; tax, financing, inflation और असाधारण downtime शामिल नहीं। असली खरीद मॉडल में लागू खर्च जोड़ें।

• SaaS base case: implementation 6,000; monthly recurring allowance 1,000।
• Self-hosted base case: implementation 12,000; monthly recurring allowance 900।
• Custom base case: implementation 45,000; monthly recurring allowance 750।

उदाहरण में कुल लागत	साल 1	साल 3	साल 5
SaaS	18,000	42,000	66,000
Self-hosted	22,800	44,400	66,000
Custom	54,000	72,000	90,000

Base case में n साल की कुल लागत = one-time implementation + 12 × n × monthly running cost। पाँचवें साल दो product options बराबर हैं क्योंकि assumptions trade-off समझाते हैं, पहले से विजेता नहीं बनाते।

• Operator का समय छोड़कर सिर्फ़ server bill को managed subscription से न तुलना करें।
• छोटे custom pilot की तुलना पूरी implemented suite से न करें। Workflow, support और recovery expectations बराबर रखें।

एक assumption बदलें तो ranking बदलती है। Self-hosted में operational support के 300 units महीने के और लगें तो पाँच साल में 18,000 जुड़ेंगे; total 84,000 होगा। SaaS usage या custom feature request किसी और option को बदल सकती है। असली लिखित quotes से low, expected और high scenarios बनाएँ, migration-out cost सहित।

दाम से ज़्यादा अहम छह बातें

१. Time to go live

छोटे scope में SaaS जल्दी शुरू हो सकता है, लेकिन access configuration, migration और training फिर भी लगते हैं। Mature self-hosted package भी जल्दी शुरू हो सकता है। छोटा custom pilot और पूरा replacement अलग काम हैं। तय दिनों के वादे के बजाय tested readiness plan की तुलना करें।

२. Cost at scale

हर billing dimension देखें: active users, sites, orders, storage, API calls, payment fees और support। सभी SaaS per-seat नहीं, सभी self-hosted licences flat नहीं। Custom में भी paid components हो सकते हैं। 10 या 15 users के नियम के बजाय अपने growth scenarios पर हिसाब करें।

3. Data ownership और residency

Data access, export करने की क्षमता और contract के rights अलग रखें। Data location की शर्त हो तो primary store, replicas, backups, logs और support access जाँचें। SaaS या self-hosting सभी obligations अपने-आप पूरे नहीं करते। अपने control के deployment में भी secure access और tested recovery चाहिए।

4. अद्वितीय प्रक्रियाओं के लिए उपयुक्त

Custom build असली process gap भर सकता है, लेकिन perfect fit की guarantee नहीं। SaaS और self-hosted दोनों में API, configuration और extensions हो सकते हैं। मुश्किल workflow दिखाएँ, unsupported हिस्से लिखें, change और future maintenance की कीमत लें। कोई universal 80/20 coverage ratio नहीं।

5. Operations burden

SaaS में infrastructure का ज़्यादा काम provider लेता है, लेकिन access decisions, configuration, data quality और recovery expectations आपकी team की रहती हैं। Self-hosting के लिए patching, monitoring, backups और incidents का तय operator चाहिए। Managed partner काम ले सकता है, पर responsibilities और response times लिखित हों। Update button restore या rollback सफल होने का प्रमाण नहीं।

6. Exit cost और lock-in

Sign करने से पहले exit की rehearsal करें। Attachments, history, identifiers और relationships वाला realistic sample export करके दूसरी जगह load करें। Formats, API limits, encryption keys, licence expiry, ongoing access और support handover जाँचें। Database query कर पाना पूरा migration plan नहीं। Custom work में source code, documentation और handover terms भी स्पष्ट चाहिए।

Score को evidence चाहिए; mandatory gates पहले

Mandatory requirements पास करने वाले options में छह factors को अपनी priorities के weights दें। 1–5 score के साथ pilot result या contract answer रखें। Weighted average = sum(weight × score) ÷ sum(weights)। ऊँचा average किसी mandatory control का failure नहीं छिपा सकता। Uncertainty लिखें। सुंदर dashboard demo के बजाय partial refund, offline sale या attachments वाला export ज़्यादा उपयोगी pilot हो सकता है।

कब कौन-सा मॉडल सही है

SaaS चुनें, अगर…

• ज़रूरी workflows pilot में चलें और provider के service/data terms आपकी ज़रूरत पूरी करें।
• Infrastructure operation खरीदना चाहते हैं और अपनी team की responsibilities स्पष्ट हैं।
• Usage और growth scenarios में पूरा quote स्वीकार्य रहता है।

Custom build चुनें, अगर…

• ज़रूरी और मूल्यवान workflow उपयुक्त product या extension में नहीं मिलता।
• सिर्फ़ version one नहीं, delivery, security, maintenance और durable handover की funding है।

Self-hosted licence चुनें, अगर…

• Product tested scope पूरा करता है और licence आपका intended use स्वीकार करता है।
• Deployment control चाहिए और सक्षम operator या managed partner की funding है।
• Licence, infrastructure, support, updates, recovery और export की संयुक्त लागत ठीक बैठती है।

Hybrid उपयोगी हो सकता है: standard capabilities खरीदें, कुछ components partner से चलवाएँ और अलग मूल्य देने वाला workflow ही बनाएँ। हर boundary पर contract, integration और recovery की ज़िम्मेदारी बढ़ती है। पूरी व्यवस्था support हो सकती है इसलिए चुनें, hybrid अपने-आप श्रेष्ठ नहीं है।

किसी भी vendor से पूछने लायक़ बारह सवाल

1. हमारे मौजूदा स्टाफ़ पर कितना ख़र्च आएगा, और स्टाफ़ तीन गुना होने पर कितना?
2. कौन-से feature मूल दाम में शामिल हैं, और किनके लिए अलग पैसे देने होंगे?
3. रिन्यूअल पर दाम कितना बढ़ सकता है, और क्या यह अनुबंध में लिखा है?
4. हमारा data ठीक-ठीक कहाँ रखा जाता है, और कौन उसे देख सकता है?
5. इतिहास और आपसी रिश्तों समेत अपना पूरा data कैसे एक्सपोर्ट करेंगे, और किस फ़ॉर्मेट में?
6. अगर हम पैसे देना बंद करें, या आपकी कंपनी बंद हो जाए, तो हमारे data का क्या होगा?
7. अपडेट कैसे आते हैं, और ख़राब अपडेट आने पर क्या पिछली स्थिति में लौट सकते हैं?
8. आपकी backup नीति क्या है, और पिछली बार backup से restore करके कब जाँचा था?
9. सुरक्षा कैसे सँभालते हैं: टू-फ़ैक्टर login, रोल, audit लॉग, encryption?
10. क्या आगे के अपडेट बिगाड़े बिना system को अपने हिसाब से बढ़ा सकते हैं?
11. क्या अपने data पर फ़्री ट्रायल मिलता है, और पैसे वापसी की कोई अवधि है?
12. बिक्री के बाद जो लोग सपोर्ट देंगे, क्या उनसे बात हो सकती है?

पाँच मिनट में decision path

1. Mandatory workflows, access limits, service और data requirements लिखें। Mandatory gate fail हो तो कम कीमत उसे पूरा नहीं कर सकती।
2. हर shortlisted option में वही मुश्किल transaction, failure और correction pilot करें।
3. समान scope के low, expected और high cost scenarios बनाएँ; assumptions और exclusions लिखें।
4. हर component को कौन चलाएगा, patch, restore और support करेगा—incident के दौरान भी—तय करें।
5. Export और handover की rehearsal करें; evidence और risks देखकर स्वीकार्य option चुनें।

StoreConsole की क़ीमत और delivery कैसे होती है

StoreConsole self-hosted, module-based licence प्रति site देता है, प्रति user नहीं। अपने configuration के लिए वर्तमान pricing, licence terms और supported deployment requirements देखें; ऊपर के sample costs हमारी quotation नहीं हैं। प्रकाशित offer में terms के अनुसार 14-day trial और 30-day money-back policy है। Trial में workflow, permissions, export और operational handover जाँचें। नीचे video में plan और checkout journey है।

मुख्य बातें

• पूरी service और workflow तुलना करें, deployment label या पहली invoice नहीं।
• Universal user-count threshold या अपने-आप सबसे सस्ता hosting model नहीं है।
• SaaS कुछ operational काम कम करता है, अपनी responsibilities नहीं मिटाता।
• Customisation या self-hosting से fit, ownership rights और compliance अपने-आप सुनिश्चित नहीं।
• Affordable exit और funded operator खरीद के फ़ैसले का हिस्सा हैं।

स्रोत और समीक्षा

समीक्षा: 4 नवंबर 2026। Microsoft की shared-responsibility guidance बताती है कि cloud services में data, identity और configuration की ज़िम्मेदारियाँ customer की भी रहती हैं। वास्तविक duties अपने contract में जाँचें। Cost table, sensitivity और scoring method समझाने के उदाहरण हैं; provider pricing या guaranteed savings नहीं।

• Microsoft Learn: shared responsibility in the cloud

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।