क्या आपको कभी ऐसा दुर्भाग्यपूर्ण प्रोजेक्ट मिला है जहां आपसे शून्य से कस्टम CRM बनाने के लिए कहा गया हो, और आप सोचते हों, "अरे, यह तो असंभव है"? मुझे यह पल दो साल पहले मिला था एक क्लाइंट के साथ जिसे अपना CRM सिर्फ 14 हफ्तों में तैयार चाहिए था। आम टाइमलाइन नहीं है। लेकिन यह सुनिए: हमारी 5-चरण रणनीति का उपयोग करके, यह न सिर्फ संभव था बल्कि काफी सुगम रहा। Stack Overflow और Postman मेरे रोजमर्रा के साथी थे। और हां, मुझने इस यात्रा में कुछ सबक सीखे।
चरण 1: खोज और दायरा तय करना (सप्ताह 1-2)
अधिकांश CRM प्रोजेक्ट एक भी कोड लिखे जाने से पहले विफल हो जाते हैं। मैं सच कह रहा हूं। विफलता एक कॉन्फ्रेंस रूम में होती है, आमतौर पर व्हाइटबोर्ड के पास, जब सभी लोग अस्पष्ट आवश्यकताओं पर सहमति दे देते हैं और कोई भी कठिन सवाल नहीं पूछता।
इस विशेष प्रोजेक्ट के साथ (बर्मिंघम में एक मध्यम आकार की लॉजिस्टिक्स कंपनी, लगभग 80 कर्मचारी), मैंने पहले दो हफ्ते लगभग सिर्फ सुनने में गंवाए। कार्यशालाएं, रिकॉर्ड किए गए Zoom कॉल, और एक साझा Notion दस्तावेज़ जहां हितधारक प्रत्येक वर्कफ़्लो डाल सकते थे जो CRM को संभालना चाहिए। दस्तावेज़ 47 पृष्ठों तक बढ़ गया। इसमें काफी कुछ विरोधाभास थे। असल में यह ठीक है, खोज के दस्तावेज़ में विरोधाभास मुफ्त होते हैं; सप्ताह 11 में खोजे गए विरोधाभास आपको एक स्प्रिंट और क्लाइंट संबंध दोनों खर्च करते हैं।
आप वास्तव में क्या मैप कर रहे हैं
डिस्कवरी का लक्ष्य हर फीचर को कैद करना नहीं है। यह डेटा रिलेशनशिप्स और यूजर रोल्स को मैप करना है जो आगे के हर आर्किटेक्चरल डिसिजन को शेप करेंगे। मैं इस स्टेज पर फ्लो डायग्राम के लिए Whimsical यूज करता हूँ। क्विक, शेयरेबल, और क्लाइंट्स अकाउंट की जरूरत के बिना कमेंट कर सकते हैं।
सप्ताह 2 के अंत तक, आपको चार डिलीवरेबल्स लॉक करने हैं:
- एक प्रायोरिटाइज़्ड फीचर लिस्ट, MVP और पोस्ट-लॉन्च बकेट्स में बाँटी गई
- एक एंटिटी-रिलेशनशिप आउटलाइन (अभी पूरी स्कीमा नहीं, सिर्फ नाउन्स: कॉन्टैक्ट्स, डील्स, पाइपलाइन्स, टास्क्स)
- यूजर रोल डेफिनिशन्स परमिशन लेवल्स के साथ प्लेन इंग्लिश में लिखे हुए
- एक साइन-ऑफ टाइमलाइन नेम्ड माइलस्टोन्स के साथ, वेग फेजेस नहीं
वह आखिरी वाला नॉन-नेगोशिएबल है। "Phase 2 complete" का कोई मतलब नहीं है। "Contact import और role-based access लाइव स्टेजिंग में day 28 तक" का मतलब है।
---
Phase 2: आर्किटेक्चर और टेक स्टैक डिसिजन्स (सप्ताह 3)
एक सप्ताह। बस इतना ही मैं इस फेज को देता हूँ, क्योंकि मैंने टीम्स को आर्किटेक्चर डिबेट्स में एक महीने के लिए गायब होते देखा है और कुछ भी शिप नहीं होता है।
इस प्रोजेक्ट के लिए स्टैक था: बैकएंड पर Node.js Express के साथ, डेटाबेस के लिए PostgreSQL, फ्रंट एंड पर React, और पूरी चीज़ को DigitalOcean managed Kubernetes पर डिप्लॉय किया गया। हमने Prisma को ORM के तौर पर इस्तेमाल किया क्योंकि स्कीमा जल्दी evolve करने वाला था और Prisma का migration workflow इसके लिए वाकई अच्छा है।
ईमानदारी से कहूँ तो स्टैक उतना मायने नहीं रखता जितना लोग सोचते हैं। जो ज्यादा मायने रखता है वो ये है:
- क्या इस प्रोजेक्ट पर हर डेवलपर को यह स्टैक बिना बहुत सीखने की मेहनत के पता होगा?
- क्या यह आर्किटेक्चर उस परमिशन मॉडल को सपोर्ट करता है जो आपने Phase 1 में मैप किया था?
- क्या आप सप्ताह 10 में एक नया entity type (जैसे "supplier") एड कर सकते हैं बिना auth layer को दोबारा लिखे?
तीसरा पॉइंट वही है जहाँ मुझे पहले जलन हुई है। 2021 में, Seahawk के पास एक SaaS प्रोजेक्ट था जहाँ हमने सप्ताह 9 में multi-tenancy जोड़ दिया। जो चीज़ दिन पहले तय की जानी चाहिए थी, उसे ठीक करने में चार दिन लग गए। फिर कभी नहीं।
Authentication के लिए, मेरा डिफ़ॉल्ट Auth0 है अगर कोई खास वजह न हो। यह edge cases को संभालता है (password resets, MFA, social login) जो junior developers को परेशान करते हैं।
---
Phase 3: Core Build Sprint (सप्ताह 4-9)
छः सप्ताह। यह इंजन रूम है। और अगर आपकी scoping सॉलिड थी, तो यह फेज़ पूरे प्रोजेक्ट का सबसे सीधा-सादा हिस्सा है।
मैंने इसे दो तीन-सप्ताह के मिनी-स्प्रिंट में बाँटा है, बीच के बिंदु पर एक कठोर आंतरिक समीक्षा के साथ।
Sprint A: Data Layer और API (सप्ताह 4-6)
जब तक API contract पर सहमति न हो जाए, कोई भी front end को छूता नहीं है। बस इतना ही। मैं Postman में हर endpoint को document करता हूँ, controller लिखने से पहले—यह tedious लगता है, लेकिन बाद में "अरे, यह endpoint क्या return करता है?" जैसी दो हफ्तों की बातचीत बचाता है।
Database schema को यहाँ अपना पहला असली पास मिलता है। CRM के लिए, जिन tables को हमेशा underestimate किया जाता है वह हैं activity log table और custom fields table। हर client को custom fields चाहिए। पहले दिन से एक flexible custom_field_definitions table को सही तरीके से बनाना लगभग चार घंटे का काम है। इसे week 11 में improvise करना एक nightmare है।
Sprint B: Front End और Workflows (सप्ताह 7-9)
React with TanStack Query server state management के लिए। मैंने 2022 में एक छोटे project पर plain useEffect और local state के साथ काम करने की कोशिश की थी। अपने आप को यह दोबारा नहीं करूँगा। TanStack Query caching, background refetching, और optimistic updates को इस तरह handle करता है कि CRM interfaces बिना किसी heroics के snappy महसूस होते हैं।
UI component layer के लिए, हमने इस project पर shadcn/ui का उपयोग किया। यह traditional sense में एक component library नहीं है; आप code के मालिक हो, जिसका अर्थ है कि आप library से लड़े बिना actually customize कर सकते हो। एक CRM के लिए जिसके पास pipeline view, contacts table, और task board है, यह flexibility मायने रखती है।
एक चीज जो इस sprint में consistently slip होती है: empty states। एक CRM जिसके पास कोई data नहीं है वह broken लगता है अगर आपने zero-state screens के लिए design नहीं किया है। इन्हें जल्दी बनाओ। Clients empty databases के साथ stakeholders को demo करते हैं और पहली impression टिक जाती है।
---
Phase 4: Integrations और Data Migration (सप्ताह 10-11)
यह वह जगह है जहाँ ज्यादातर एजेंसियाँ कम कोट देती हैं और कम योजना बनाती हैं। मैंने इसे हर बार देखा है।
बर्मिंघम लॉजिस्टिक्स क्लायंट को उनके मौजूदा Xero अकाउंटिंग सेटअप के साथ इंटीग्रेशन की जरूरत थी और एक पुराने Salesforce इंस्टेंस के साथ जिससे वे माइग्रेट कर रहे थे। दो हफ्ते तंग लगते हैं। था भी, लेकिन हम इसलिए कर पाए क्योंकि हमने Phase 3 में ही इंटीग्रेशन पॉइंट्स को स्टब कर रखा था।
Salesforce माइग्रेशन के लिए खास तौर पर, हमने उनके Bulk API 2.0 का इस्तेमाल डेटा निकालने के लिए किया, फिर इसे एक Node स्क्रिप्ट के जरिए चलाया जिसने उनकी फील्ड स्ट्रक्चर को हमारी स्ट्रक्चर में मैप किया। स्क्रिप्ट लिखने में एक दिन लगा और इटरेट करने में तीन दिन क्योंकि Salesforce डेटा लगभग कभी भी उतना साफ नहीं होता जितना क्लायंट सोचते हैं। डेटा क्लीनिंग के लिए बजट रखें। हमेशा।
इंटीग्रेशन को "पूरा" कहलाने से पहले मैं कुछ चीजें चेक करता हूँ:
- फेलियर हैंडलिंग: जब थर्ड-पार्टी API डाउन हो जाता है तो क्या होता है?
- Webhook इडेम्पोटेंसी: क्या आप एक ही इवेंट को दो बार सुरक्षित तरीके से प्रोसेस कर सकते हैं बिना रिकॉर्ड दोगुने किए?
- रेट लिमिट्स: क्या आप यथार्थवादी लोड के तहत उनके अंदर हैं?
Xero डेवलपर डॉक्स दरअसल अच्छे हैं, जो कुछ है। OAuth 2.0 फ्लो अच्छी तरह डॉक्यूमेंटेड है और उनका सैंडबॉक्स एनवायरनमेंट विश्वसनीय तरीके से काम करता है।
---
Phase 5: QA, हार्डनिंग, और हैंडओवर (हफ्ते 12-14)
QA के लिए तीन हफ्ते उदार लगते हैं जब तक आप उसमें नहीं होते।
सप्ताह 12 संरचित परीक्षण है। मैं क्लाइंट को एक ClickUp बोर्ड देता हूँ जिसमें हर टेस्ट केस को एक कार्य के रूप में लिखा होता है, वे परीक्षण करते हैं, इसे चिह्नित करते हैं, और अगर कुछ टूटता है तो एक Loom संलग्न करते हैं। इससे असली उपयोगकर्ता असली प्रवाहों पर क्लिक करते हैं, जो हमेशा उन चीज़ों को उजागर करता है जो डेवलपर द्वारा चलाई गई परीक्षा मिस करती है। कोई "नोट्स" फील्ड में 4,000 वर्ण पेस्ट करने की कोशिश करेगा। कोई स्मार्ट कोट्स वाली CSV आयात करेगा। आप इसे अभी खोजना चाहते हैं।
सप्ताह 13 फिक्स स्प्रिंट है। कोई नई सुविधाएँ नहीं। केवल बग फिक्स और परफॉर्मेंस का काम। मैं हर मुख्य पृष्ठ पर Lighthouse चलाता हूँ। मैं API के विरुद्ध k6 लोड टेस्ट भी चलाता हूँ, इसलिए नहीं कि क्लाइंट ने इसके लिए कहा, बल्कि इसलिए कि सप्ताह 13 में 50 साथी उपयोगकर्ताओं के तहत एक धीमी क्वेरी खोजना go-live के बाद इसे खोजने से बेहतर है।
सप्ताह 14 हैंडओवर और go-live की तैयारी है।
मैं जो हैंडओवर दस्तावेज़ तैयार करता हूँ उसमें शामिल है:
- अवसंरचना अवलोकन (क्या कहाँ चल रहा है, इसे कैसे स्केल करें)
- डेटाबेस बैकअप और पुनर्स्थापन प्रक्रिया, परीक्षित और सत्यापित
- कोड को छुए बिना नई उपयोगकर्ता भूमिका कैसे जोड़ें
- ज्ञात सीमाएँ और बैकलॉग आइटम जिन्हें हमने स्थगित किया
यह आखिरी वाला महत्वपूर्ण है। जो कुछ शामिल नहीं हुआ उसके बारे में ईमानदार रहें। क्लाइंट इसका सम्मान करते हैं, और यह अगले चरण के काम को साफ-सुथरे तरीके से स्थापित करता है बजाय अनकहे कर्ज को रिश्ते पर लटकने देने के।
Go-Live पर एक आखिरी बात
इसे धीरे-धीरे करें। हमने दिन 92 पर 10 उपयोगकर्ताओं के साथ soft-launch किया, Datadog का उपयोग करके 48 घंटे तक लॉग देखे, फिर इसे पूरी 80-सदस्यीय टीम के लिए खोल दिया। उस 48-घंटे की खिड़की ने पाइपलाइन स्टेज ट्रांजिशन में दो edge cases पकड़े जो परीक्षण में सामने नहीं आए थे। कुछ भी विनाशकारी नहीं, लेकिन यह वह तरह की चीज़ थी जो अगर हमने पूरी ताकत से जाते तो पहले दिन 15 सपोर्ट टिकट बनाई होती।
Go-live अंत नहीं है। यह तब शुरू होता है जब वास्तविक उपयोगकर्ता व्यवहार डेटा आने लगता है।
---
FAQ
इस तरह का कस्टम CRM आमतौर पर कितना खर्च आता है?
ईमानदारी से कहूँ तो यह बहुत अलग-अलग होता है, लेकिन एक 14-सप्ताह की प्रोजेक्ट जो इस स्तर पर स्कोप की गई हो और एक छोटी टीम के साथ (दो back-end डेवलपर्स, एक front-end डेवलपर, एक प्रोजेक्ट लीड) आमतौर पर £60,000 से £120,000 के बीच चलती है, यह integrations और data migration की जटिलता पर निर्भर करता है। अगर आप एक पूरे कस्टम बिल्ड के लिए £30,000 से कम के quotes देख रहे हैं, तो इस पर ज़ोर दें कि वास्तव में क्या बनाया जा रहा है बनाम किसी मौजूदा टेम्प्लेट से कॉन्फ़िगर किया जा रहा है।
क्या आप WordPress पर एक कस्टम CRM बना सकते हैं?
आप बना सकते हैं, लेकिन मैं लगभग 500 records या 20 concurrent users से ऊपर किसी भी चीज़ के लिए नहीं करूँगा। WordPress की data layer relational CRM workloads के लिए डिज़ाइन नहीं किया गया है। Seahawk में हमने छोटे clients के लिए WordPress के शीर्ष पर contact management layers बनाए हैं, लेकिन किसी भी गंभीर चीज़ के लिए, एक proper back end जिसमें relational database हो, यही सही कॉल है।
CRM builds पर टीमें सबसे बड़ी गलती क्या करती हैं?
अनुमति मॉडल को कम परिभाषित करना। सभी फीचर पर ध्यान केंद्रित करते हैं और यह भूल जाते हैं कि 80 उपयोगकर्ताओं वाले CRM को "कौन कौन सा डील देख सकता है?" का एक सूक्ष्म उत्तर चाहिए, इससे पहले कि आप एक भी API route लिखें। सप्ताह 10 में भूमिका-आधारित एक्सेस नियंत्रण को फिर से तैयार करना इतना पीड़ादायक है कि जब तक आपने इसे एक बार न कर लिया हो, तब तक इसे वर्णित करना मुश्किल है।
क्या आप हमेशा यह सटीक तकनीकी स्टैक उपयोग करते हैं?
नहीं। मैंने जिस स्टैक का वर्णन किया, वह इस प्रोजेक्ट की टीम और बाधाओं के लिए काम करता था। मैंने Laravel और Vue पर CRM, Django और React पर, और एक बार Next.js पूर्ण-स्टैक सेटअप पर लॉन्च किया है जिसके बारे में मुझे संदेह था लेकिन वास्तव में बहुत अच्छी तरह काम किया। आर्किटेक्चर सिद्धांत समान रहते हैं। उपकरण लचीले होते हैं।
अंत में, कस्टम CRM प्रोजेक्ट केवल एक चुनौती नहीं था, बल्कि एक प्रकाशन था। वह कड़ी 14-सप्ताह की खिड़की? इसने हमें नवाचार करने, अनुकूल बनाने और डिलीवर करने के लिए मजबूर किया। पता चला है कि बाधाएँ रचनात्मकता के लिए एक प्रेरक हो सकती हैं। कौन जानता था कि समय सीमा हमें अपने काम के बारे में इतना कुछ सिखा सकती है? ऐसे प्रोजेक्ट हैं जो मुझे यह याद दिलाते हैं कि मैंने Seahawk Media की स्थापना क्यों की।