मुझे वह पल बिल्कुल कल की तरह याद है: जब HubSpot मेरे क्लाइंट की जरूरतों के साथ तालमेल नहीं बिठा सका। यह 2023 की बात थी, Shoreditch का एक तेजतर्रार टेक स्टार्टअप। हम HubSpot का इस्तेमाल करके एक प्रोजेक्ट में गहरे उतरे हुए थे और हमें एहसास हुआ कि क्लाइंट का यूनिक सेल्स फनल बिल्कुल मेल नहीं खा रहा था। ये टूल्स काफी लचकदार नहीं थे। उन्हें कुछ कस्टम चाहिए था, कुछ ऐसा जो उनके साथ विकसित हो। तो मैंने एक बेस्पोक CRM डेवलप करने में जी-जान लगा दी। हमने Node.js से लेकर Airtable तक सबकुछ इस्तेमाल किया, हर टूल को इस तरह ढाला कि वह परफेक्ट फिट हो। यह आँखें खोल देने वाला अनुभव था।
असली संकेत कि HubSpot की सीमा आ गई है
ज़्यादातर एजेंसी मालिक जिनसे मैं बात करता हूँ, नहीं समझते कि HubSpot समस्या है। वे सोचते हैं कि समस्या उनकी प्रक्रिया में है, या उनकी टीम में, या उनके डेटा हाइजीन में। यह शायद ही कभी होता है।
यहाँ वे संकेत हैं जिन पर मैं ध्यान देता हूँ:
- आपकी सेल्स टीम ने एक दूसरी स्प्रेडशीट बना ली है ताकि वह चीज़ें ट्रैक कर सके जो HubSpot "तकनीकी रूप से" तो करता है पर ख़राब तरीके से।
- आप HubSpot के किसी tier के लिए भुगतान कर रहे हैं सिर्फ एक या दो features तक पहुँचने के लिए जिन्हें आप वास्तव में use करते हैं
- आपके developers ने दो से अधिक custom-coded workflow extensions लिख दिए हैं
- Reporting के लिए Google Sheets में export करना पड़ता है क्योंकि HubSpot के native dashboards आपके ज़रूरत के डेटा को join नहीं कर सकते
- आप peak usage hours के दौरान HubSpot के standard endpoints पर API rate limits को hit कर रहे हैं
वह आखिरी वाला अंडररेटेड है। मेरे पास 2024 के mid में B2B logistics में एक client था जो एक third-party integration के through 40,000+ contact updates per day चला रहा था। HubSpot की API limits queuing delays का कारण बन रही थीं जिससे उनका automated outreach sync से बाहर हो गया। वे हमेशा अपनी ops team को blame करते थे। यह platform था।
अपने आप से पूछने वाला ईमानदार सवाल यह है: क्या आप अपने business logic को CRM में fit करने के लिए bend कर रहे हैं, या CRM आपके लिए bend हो रहा है? अगर पहला है, तो आप पहले से ही जमीन खो रहे हैं।
जब Maths वास्तव में काम करता है
Custom CRM builds upfront में महंगे होते हैं। मैं इसका नकाब नहीं सजाऊँगा। एक well-scoped build एक solid team के साथ आपको £25,000 से £120,000 तक कहीं भी खर्च करेगा जो complexity, integrations, और इस बात पर निर्भर करता है कि क्या आप top पर एक mobile layer चाहते हैं।
लेकिन HubSpot का Enterprise tier £3,600+ per month है। वह £43,200 एक साल है, add-ons से पहले, Ops Hub से पहले, किसी भी third-party connectors से पहले जिनके लिए आप अलग से भुगतान कर रहे हैं। तीन साल में, आप एक ऐसे platform पर £130,000 से अधिक देख रहे हैं जिसे आप own नहीं करते और core level पर modify नहीं कर सकते।
Maths ज्यादातर लोगों की उम्मीद से तेजी से shift होता है।
कोड की एक भी पंक्ति लिखने से पहले सही आर्किटेक्चर चुनें
यहीं मैंने सबसे महंगी गलतियां देखी हैं। लोग आर्किटेक्चर तय किए बिना बिल्डिंग शुरू कर देते हैं, फिर छह महीने रीफैक्टरिंग में लगाते हैं। Seahawk के पास 2024 की शुरुआत में एक फिनटेक प्रोजेक्ट था जहां क्लायंट ने हमारे शामिल होने से पहले एक मोनोलिथिक Laravel सेटअप पर एक CRM बिल्ड करना शुरू कर चुका था। उन्होंने डेटा रिलेशनशिप के बारे में ऐसी धारणाएं बना दी थीं जो तीन लेयर्स गहराई में बेक हो गई थीं। हम पहले चार हफ्ते अनटैंगलिंग में लगाए, बिल्डिंग में नहीं।
दो आर्किटेक्चरल फैसले जो शुरुआत में सबसे ज्यादा मायने रखते हैं:
Monolith बनाम Service-Oriented
ज्यादातर CRM बिल्ड्स में जो एक निश्चित स्केल से नीचे होते हैं (मान लीजिए, 500 से कम कॉनकरेंट इंटरनल यूजर्स), एक अच्छी तरह से स्ट्रक्चर्ड monolith अभी भी बिल्कुल ठीक है। Rails, Laravel, Django। ये सबसे अच्छे तरीके से बोरिंग हैं। आप तेजी से आगे बढ़ सकते हैं, और आप उन सर्विसेज के बीच कम्युनिकेशन को डिबग करते हुए समय बर्बाद नहीं करते जब आपको फीचर्स शिप करने चाहिए।
Service-oriented architecture तब समझ में आता है जब आपके पास सच में अलग-अलग डोमेन्स हों जिन्हें स्वतंत्र रूप से स्केल करने की जरूरत हो। जैसे अगर आपका CRM एक कस्टमर-फेसिंग पोर्टल भी चलाता है जिसमें रीयल-टाइम डेटा हो, और एक अलग एनालिटिक्स इंजन, और एक मोबाइल ऐप हो। उस बिंदु पर, कंसर्न्स को अलग करना सार्थक हो जाता है।
किसी को माइक्रोसर्विसेज बेचने दें क्योंकि यह आधुनिक लगता है। मैंने बहुत सारे £60k बिल्ड्स देखे हैं जो £25k के monolith होने चाहिए थे।
Relational बनाम Document Store
ज्यादातर CRM डेटा सहज रूप से relational होता है। Contacts के कंपनीज होते हैं। कंपनीज के deals होते हैं। Deals के activities होते हैं। PostgreSQL इसे असाधारण रूप से संभालता है और इसका JSON सपोर्ट इतना परिपक्व हो गया है कि आपको document store की flexibility मिलती है जब आपको सच में इसकी जरूरत हो, बिना relational integrity को छोड़े।
MongoDB तब समझ में आता है जब आपके contact रिकॉर्ड्स आपके यूजर बेस में स्ट्रक्चर में बेतरतीब असंगत हों। यह कुछ बिजनेसेज के लिए एक वास्तविक परिस्थिति है। ज्यादातर के लिए, यह नहीं है।
मेरा 2026 में डिफ़ॉल्ट: PostgreSQL, हर बार, जब तक सिद्ध न हो जाए कि अन्यथा है।
टेक स्टैक जो मैं 2026 में वास्तव में सुझाऊँगा
यहाँ कोई सैद्धांतिक उत्तर नहीं है। यह वह है जो मैं अभी के साथ बनाऊँगा।
- बैकएंड: Node.js के साथ Fastify या Python के साथ FastAPI। विशेष रूप से Fastify CRM बैकएंड के लिए अपराध से कम उपयोग किया जाता है। यह Express से तेज़ है, स्कीमा वैलिडेशन बिल्ट इन है, और प्लगइन ईकोसिस्टम 2022 के बाद से काफ़ी परिपक्व हो गया है।
- डेटाबेस: PostgreSQL 16, Prisma के साथ ORM के रूप में यदि आप Node-land में हैं, या SQLAlchemy यदि Python। हर चीज़ के लिए हाथ से SQL न लिखें। आप छह महीने में अपने आप को धन्यवाद दिलवाएँगे।
- ऑथ: Auth0 या Clerk। 2026 में अपना ऑथ बनाना एक विकल्प है जिसे मैं वास्तव में समझ नहीं पाता। विशेष रूप से Clerk मेरा जाने-माने विकल्प बन गया है किसी भी चीज़ के लिए जिसे multi-tenant organisation सपोर्ट की ज़रूरत है बॉक्स से बाहर।
- फ्रंटएंड: Next.js 14+ के साथ App Router। सर्वर कंपोनेंट शिफ्ट ने वास्तव में बदल दिया है कि इंटरनल टूल्स एंड यूज़र्स को कितने तेज़ लगते हैं।
- ईमेल/कम्युनिकेशन लेयर: ट्रांज़ैक्शनल ईमेल के लिए Resend, आवश्यकता पड़ने पर SMS के लिए Twilio। दोनों के पास सही APIs हैं जिनकी दरें समझदारीपूर्ण हैं।
- बैकग्राउंड जॉब्स: Redis पर BullMQ। CRMs बहुत सारे async काम करते हैं: सिंकिंग, स्कोरिंग, रिमाइंडर। आपको एक विश्वसनीय queue की ज़रूरत है।
- सर्च: यदि फुल-टेक्स्ट कॉन्टैक्ट/कंपनी सर्च एक मुख्य फीचर है, तो Meilisearch को जल्दी जोड़ें। यह self-hostable है, तेज़ है, और Elasticsearch चलाने से कहीं अधिक आसान है।
यह 85% कस्टम CRM बिल्ड्स के लिए एक पूरा स्टैक है जिनका मैं सामना करता हूँ। बाकी 15% में मोबाइल या real-time requirements होती हैं जो React Native या WebSockets को मिक्स में जोड़ देती हैं।
Data Migration: वह हिस्सा जिसे हर कोई कम आंकता है
सच कहूँ तो, data migration ही वह जगह है जहाँ प्रोजेक्ट्स चुपचाप पटरी से उतरते हैं। बिल्ड नहीं। Migration।
अगर आप HubSpot से माइग्रेट कर रहे हैं, तो एक्सपोर्ट आपके सोचने से ज्यादा गड़बड़ा हुआ होगा। HubSpot का data model बहुत सारे implicit associations रखता है। Contacts और companies के बीच associations export CSV में हमेशा क्लीन नहीं होती हैं। Custom properties internal field names के साथ आती हैं जो display labels से मेल नहीं खाते। Deal stages को numeric IDs से reference किया जाता है जिन्हें आपको मैन्युअली cross-reference करना पड़ता है।
मैं mid-size HubSpot instance (कहते हैं, 50,000 contacts, 10,000 deals) के लिए कम से कम चार हफ्तों के dedicated migration work का budget करूँगा। इसमें शामिल है:
- हर custom property को audit और map करना
- Transformation scripts लिखना (Python इसके लिए शानदार है, खासकर pandas messy intermediate steps के लिए)
- Cutover से पहले कम से कम दो हफ्तों तक parallel systems चलाना
- एक rollback plan बनाना। हमेशा rollback plan बनाना।
अगर आप parallel running को छोड़ देते हैं, तो आपको पछतावा होगा। मेरे एक क्लाइंट ने Friday को दोपहर hard cutover किया। Monday तक उन्हें तीन data integrity issues मिल गए जिन्हें ठीक करने में दो हफ्ते लगे। एक live production system पर। ऐसे व्यक्ति मत बनिए।
इंटीग्रेशन जो कस्टम बिल्ड में वाकई मायने रखते हैं
CRM अलग-थलग नहीं रहता। आपको इसे हमेशा कुछ न कुछ से कनेक्ट करना होगा। यहाँ मैं अपना ज्यादातर इंटीग्रेशन समय खर्च करता हूँ:
फाइनेंस और बिलिंग
ज्यादातर UK-आधारित क्लाइंट के लिए QuickBooks या Xero। दोनों के पास सॉलिड APIs हैं। सबसे जरूरी चीज़ है सत्य की दिशा को सही तरीके से समझना: क्या CRM डील वैल्यूज़ के लिए सत्य का स्रोत है, या अकाउंटिंग सिस्टम? एक को चुनिए। स्पष्ट प्राधिकार के बिना बिडायरेक्शनल सिंक ऐसे conflicts का कारण बनता है जिन्हें रात 11 बजे डिबग करना सच में दर्दनाक होता है।
कैलेंडर और कम्युनिकेशन
Google Workspace और Microsoft 365 आवश्यक हैं। Google का Calendar API अच्छी तरह दस्तावेज़ित और विश्वसनीय है। Microsoft Graph API शक्तिशाली है लेकिन सीखने का कर्व थोड़ा ज़्यादा खड़ा है। इसके अनुसार बजट करें।
मार्केटिंग ऑटोमेशन
यह वह जगह है जहाँ लोग अक्सर HubSpot का एक हिस्सा रखना चाहते हैं, खासकर मार्केटिंग की तरफ, जबकि सेल्स CRM को बदल देते हैं। यह पूरी तरह से वैध हाइब्रिड दृष्टिकोण है। HubSpot के API का उपयोग करके contact updates और deal stage changes को मार्केटिंग लिस्ट्स में वापस भेजें। यह तब अच्छी तरह काम करता है जब डेटा कॉन्ट्रैक्ट स्पष्ट रूप से परिभाषित हो।
बिल्ड बनाम बाय बनाम हाइब्रिड: फैसला करना
मुझसे इसके बारे में लगातार पूछा जाता है। और कोई सर्वव्यापी जवाब नहीं है, लेकिन मेरे पास एक फ्रेमवर्क है जो मैं उपयोग करता हूँ।
खरीदें (HubSpot, Salesforce, Pipedrive) जब: आपकी बिक्रय प्रक्रिया अपेक्षाकृत मानक है, CRM का उपयोग करने वाले लोगों की संख्या 20 से कम है, और आप महीनों की बजाय हफ्तों के भीतर operational होना चाहते हैं।
कस्टम बनाएं जब: आपके पास वास्तव में अनोखे डेटा संबंध या वर्कफ़्लो लॉजिक हैं, आपको स्वामित्व वाली आंतरिक प्रणालियों के साथ गहरे एकीकरण की आवश्यकता है, या आपने गणना की है कि 36 महीने में प्लेटफ़ॉर्म की लागत आपके निर्माण अनुमान से अधिक है।
हाइब्रिड जब: आपको marketing automation और brand-name integrations की आवश्यकता है जो HubSpot जैसे प्लेटफ़ॉर्म के साथ आते हैं, लेकिन आपकी core CRM लॉजिक को किसी ऐसी जगह रहने की जरूरत है जिस पर आप नियंत्रण रखते हैं। यह लोग मानते हैं उससे ज्यादा common है। हमने 2025 में एक SaaS क्लाइंट के लिए यह मॉडल चलाया जहां कस्टम CRM ने सभी deal लॉजिक और contract management को संभाला, लेकिन HubSpot marketing hub के रूप में रहा। दोनों के बीच clean API contract। बिल्कुल काम किया।
सबसे बुरा नतीजा यह है कि नौ महीने एक कस्टम CRM बनाने में लगाएं जो बिल्कुल वही करता है जो HubSpot करता है, लेकिन बदतर। यह होता है। आमतौर पर जब कस्टम बनाने का निर्णय भावनात्मक रूप से किया गया हो analytical रूप से नहीं।
FAQ
एक कस्टम CRM निर्माण वास्तव में कितना समय लेता है?
यथार्थवादी समयरेखा: core contact management, deal tracking, और basic reporting के साथ एक lean MVP को दो से तीन व्यक्ति की team के साथ लगभग 10 से 14 सप्ताह लगते हैं। Multiple integrations, कस्टम reporting, और एक mobile layer वाले full-featured builds छह से नौ महीने तक पहुंचते हैं। कोई भी आपको किसी जटिल चीज के लिए चार सप्ताह का quote दे रहा है तो वह या तो corners काटने की योजना बना रहा है या project को सही तरीके से scope नहीं किया है।
क्या मैं कस्टम CRM को self-host कर सकता हूं और लागत कम रख सकता हूं?
हां, और कई क्लाइंट्स के लिए यह सही फैसला है। Render या DigitalOcean managed database cluster जैसी किसी चीज़ पर एक well-configured setup आपकी infrastructure लागत को predictable रखता है। मैंने ऐसे CRMs देखे हैं जो 10,000+ contacts को serve करते हैं और £80 प्रति महीने hosting पर comfortably चलते हैं। variable cost maintenance और updates है, server bill नहीं।
कस्टम CRM बनाते समय teams सबसे बड़ी गलती क्या करते हैं?
भविष्य के लिए निर्माण करो जो वे कल्पना करते हैं, वर्तमान के लिए नहीं जो उनके पास है। मैंने टीमों को AI-चालित लीड स्कोरिंग, predictive pipeline forecasting, और एक पूर्ण मोबाइल ऐप specify करते देखा है, इससे पहले कि वे बेसिक contact deduplication को सही तरीके से handle भी करें। पहले बोर वाली चीजें सही करो। Deduplication, data validation, audit logs, user permissions। ये चीजें unglamorous हैं और बिल्कुल critical हैं। बाकी सब कुछ optional है जब तक ये solid न हों।
क्या HubSpot से माइग्रेट करना सच में इतना मुश्किल है?
उनके documentation से कहीं ज्यादा मुश्किल, Salesforce से आसान। मुख्य friction custom properties, workflow logic, और email sequence history से है। Contact और deal data itself reasonably cleanly export हो जाता है। Workflow logic में surprises के लिए तैयार रहो। HubSpot workflows अक्सर business rules को encode करते हैं जो किसी ने और कहीं लिख नहीं रखे हैं, और तुम्हें माइग्रेशन के आधे रास्ते में ही पता चलेगा।
उस Shoreditch प्रोजेक्ट के बारे में सोचते हुए, यह साफ है: कभी-कभी तैयारीशुदा समाधान काम नहीं आते। कस्टम CRM डेवलपमेंट सिर्फ आखिरी उपाय नहीं है; यह उन लोगों के लिए एक सक्रिय विकल्प है जो सामान्य से आगे जाने के लिए तैयार हैं। जैसे-जैसे बिजनेस बढ़ता है, उसके टूल्स को भी बढ़ना चाहिए। सही CRM आपकी संभावनाओं को अनलॉक करने की कुंजी हो सकता है, लेकिन ऐसा लगना चाहिए कि वह सिर्फ आपके लिए ही बनाया गया था। और कभी-कभी, इसका मतलब है अपनी बाजुओं को मोड़ना और शुरुआत से शुरू करना।
संबंधित पढ़ें: AI सर्च कीवर्ड रिसर्च 2026 में: यह क्या है, क्यों पारंपरिक, तकनीकी SEO, और AI सर्च।