मैंने Courtlines कैसे बनाया: Claude के साथ इंजीनियर किया गया एक क्लब-मैनेजमेंट SaaS

विषय-सूची

जुलाई 2026 में अपडेट किया गया।

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

[ऑपरेटर का नज़रिया] मैं एक कंसल्टिंग ब्रांड और Pickleland — Austin, TX महानगर में मेरे द्वारा संचालित पिकलबॉल सुविधा — में 30 से अधिक प्रोडक्शन एजेंट चलाता हूँ। एक असली सुविधा चलाने से मुझे ठीक-ठीक समझ आया कि मेरे जैसे क्लबों के लिए सॉफ़्टवेयर कितना खराब है — तो मैंने वह सॉफ़्टवेयर बनाया जो मैं चाहता था कि मेरे पास होता। यह Courtlines की कहानी है, यह क्या करता है, और कैसे Claude पर टेक लगाने से एक अकेले इंसान को कुछ ऐसा बनाने में मदद मिली जिसके लिए आम तौर पर एक पूरी टीम लगती है।

क्लब को एक ऐप नहीं, बल्कि एक ऑपरेटिंग सिस्टम की ज़रूरत क्यों है

अगर आपने कभी कोई स्पोर्ट्स सुविधा नहीं चलाई है, तो सॉफ़्टवेयर की समस्या अदृश्य रहती है। बाहर से देखने पर ऐसा लगता है कि “लोग कोर्ट बुक करते हैं।” अंदर से, एक क्लब एक छोटा, गड़बड़ बिज़नेस है जिसमें दर्जनों चलते-फिरते हिस्से होते हैं जिन्हें आपस में सहमत रहना ज़रूरी है।

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

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

Courtlines इस सवाल का जवाब है कि “अगर यह सब एक ही सिस्टम होता तो क्या होता?” यह फ़ीचर जोड़-जोड़ कर बनाई गई कोई बुकिंग ऐप नहीं है — यह एक अकेला ऑपरेटिंग सिस्टम है जहाँ कैलेंडर, मेंबरशिप, रजिस्टर, कोचिंग भुगतान और सार्वजनिक इवेंट पेज सब एक ही अंतर्निहित डेटा हैं। यही पूरी थीसिस है, और यही साइट पर टैगलाइन भी है: क्लबों और स्टूडियो के लिए ऑपरेटिंग सिस्टम।

Courtlines असल में क्या करता है

मोटे तौर पर, Courtlines एक क्लब को देता है:

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

डिज़ाइन का लक्ष्य यह है कि प्लेटफ़ॉर्म गायब हो जाए। एक क्लब अपना खुद का ब्रांड ऊपर लगाता है, और उसके मेंबरों को यह बस “हमारे क्लब का ऐप” जैसा लगता है, न कि “कोई SaaS जिसके लिए हम पैसे देते हैं।” यह इस क्षेत्र के मौजूदा खिलाड़ियों — CourtReserve और Skedda जैसों — से एक जानबूझकर किया गया विरोधाभास है, जहाँ सॉफ़्टवेयर ही ब्रांड है और क्लब बस एक किरायेदार।

Pickleland टेनेंट #1 है। मुझे किसी डेमो के पीछे छिपने की सहूलियत नहीं मिलती; इस चीज़ को असल में एक ऐसी सुविधा चलानी होती है जिसकी ज़िम्मेदारी व्यक्तिगत रूप से मुझ पर है। यह बाधा अब तक की मेरी सबसे बढ़िया प्रोडक्ट मैनेजर रही है। आप Pickleland यहाँ देख सकते हैं — यह असल दुनिया की परख का मैदान है, और हर वह खुरदरा किनारा जिससे कोई मेंबर टकराता है, एक बग है जिसे मैं उसी दिन महसूस करता हूँ।

जिस बात ने मुझे चौंका दिया: एक अकेला ऑपरेटर अब क्या शिप कर सकता है

यह कहानी का ईमानदार संस्करण है, और यही वजह है कि मैं चुपचाप लॉन्च करने के बजाय यह पोस्ट लिख रहा हूँ।

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

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

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

मैं जानबूझकर यहाँ Courtlines के लिए अपनी सटीक ऑपरेटिंग रणनीति प्रकाशित नहीं कर रहा — उसे मैं एक प्रतिस्पर्धी बढ़त मानता हूँ, और मैं चाहूँगा कि मेरे प्रतिस्पर्धी यही मानते रहें कि इसमें एक बड़ी टीम लगती है। लेकिन अगर आप देखना चाहते हैं कि मैं किसी असली प्रोजेक्ट पर Claude को कैसे चलाता हूँ, विस्तार से, तो मैंने यह सब एक बहुत छोटे बिल्ड के लिए लिख डाला: एक मोबाइल गेम जो मैंने ऐप स्टोर पर शिप किया। देखें मैंने Quads, एक मोबाइल बोर्ड गेम, Claude के साथ कैसे बनाया — वही काम करने का तरीका, कुछ भी छिपाने को नहीं, हर तरकीब मेज़ पर।

वे सिद्धांत जिन पर मैं समझौता नहीं करूँगा

रणनीति को निजी रखते हुए भी, कुछ सिद्धांत कहने लायक हैं क्योंकि वे किसी भी उस व्यक्ति पर लागू होते हैं जो AI के साथ गंभीर सॉफ़्टवेयर बना रहा है:

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

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

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

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

यह मेरी बाकी बनाई जा रही हर चीज़ में कहाँ फ़िट बैठता है

Courtlines अलग-थलग नहीं है। यह एक छोटे रैकेट-स्पोर्ट्स इकोसिस्टम का हिस्सा है जिसे मैं बना रहा हूँ: The Court Scout पिकलबॉल कोर्टों की एक सत्यापित डायरेक्टरी है, जिसे उन स्क्रैप की गई डायरेक्टरियों से सचमुच ज़्यादा सटीक बनाने के लिए बनाया गया है जिनसे यह मुकाबला करती है, और Pickleland वह प्रमुख सुविधा है जिसके ख़िलाफ़ हर चीज़ की परख होती है। डायरेक्टरी खिलाड़ियों को कोर्ट खोजने में मदद करती है; Courtlines उन कोर्टों के पीछे के क्लबों को असल में चलने में मदद करता है।

इन सब को जोड़ने वाली कड़ी एक ही ऑपरेटिंग मॉडल है: AI से सशक्त एक अकेला ऑपरेटर, जो एक अकेला ऑपरेटर ऐतिहासिक रूप से जितनी संभाल सकता था उससे ज़्यादा दायरा संभाल रहा है। Courtlines अब तक इस मॉडल की सबसे महत्वाकांक्षी अभिव्यक्ति है — एक पूरा SaaS प्लेटफ़ॉर्म जिसे कुछ साल पहले मैं अकेले करने की कोशिश ही नहीं करता।

अगर आप कोई रैकेट-स्पोर्ट्स क्लब या स्टूडियो चलाते हैं और चार टूल्स को आपस में जोड़ते-जोड़ते थक गए हैं, तो Courtlines पर एक नज़र डालिए। और अगर आप एक बिल्डर हैं जो सोच रहे हैं कि किसी असली उत्पाद पर आप AI को कितनी दूर तक धकेल सकते हैं, तो यही इस पोस्ट का पूरा मकसद है: शायद आपकी सोच से भी दूर।

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

Courtlines क्या है?

Courtlines रैकेट-स्पोर्ट क्लबों और स्टूडियो के लिए एक मल्टी-टेनेंट ऑपरेटिंग सिस्टम है — पिकलबॉल, टेनिस, पैडल और उससे आगे। यह बुकिंग, मेंबरशिप, कोचिंग, पॉइंट-ऑफ-सेल और इवेंट प्रबंधन को एक ब्रांडेड प्लेटफ़ॉर्म में जोड़ता है, ताकि एक क्लब अपना पूरा बिज़नेस चार अलग-अलग जुड़े हुए टूल्स के बजाय एक ही सिस्टम से चलाए। आप इसे courtlines.com पर देख सकते हैं।

क्या Claude ने सचमुच ज़्यादातर कोड लिखा?

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

क्या एक अकेला इंसान सचमुच AI के साथ इतना बड़ा SaaS बना और चला सकता है?

इसे बनाना अब सचमुच व्यवहार्य है — यही चौंकाने वाला हिस्सा है। बड़ी चुनौती इसे चलाना और बनाए रखना है, क्योंकि एक बड़े कोडबेस को किसी ऐसे इंसान की ज़रूरत होती है जो आर्किटेक्चर को समझता हो, भले ही ब्योरा AI ने लिखा हो। कुंजी है साफ़ विनिर्देश बनाए रखना और उन थोड़ी-सी ज़्यादा-जोखिम वाली क्रियाओं पर अडिग रहना जिन्हें इंसान को संभालना ज़रूरी है। इस तरह किया जाए, तो एक अकेले ऑपरेटर के लिए बनाए रखने लायक दायरा पहले से कहीं ज़्यादा बड़ा है।

CourtReserve या Skedda इस्तेमाल करने के बजाय अपना खुद का क्लब सॉफ़्टवेयर क्यों बनाया?

क्योंकि Pickleland चलाने से मुझे ठीक-ठीक दिखा कि मौजूदा टूल्स कहाँ कम पड़ते हैं: बुकिंग सिस्टम, रजिस्टर और मेंबरशिप एक ही सत्य के स्रोत को साझा नहीं करते, तो कुछ भी साफ़-सुथरे तरीके से मेल नहीं खाता। मुझे एक ऐसा सिस्टम चाहिए था जहाँ यह सब एक ही अंतर्निहित डेटा हो और जहाँ मेंबरों को क्लब का ब्रांड दिखे — न कि सॉफ़्टवेयर वेंडर का। यही वह खाई है जिसे पाटने के लिए Courtlines बनाया गया है।

मैं यह कहाँ सीख सकता हूँ कि आप रोज़ाना Claude के साथ असल में कैसे काम करते हैं?

मैं प्रतिस्पर्धी कारणों से विस्तृत Courtlines रणनीति निजी रखता हूँ, लेकिन मैंने ठीक वही काम करने का तरीका एक छोटे, पूरी तरह खुले प्रोजेक्ट पर दस्तावेज़ किया — Quads नाम का एक मोबाइल बोर्ड गेम। मैकेनिक्स के लिए पढ़ें मैंने Quads, एक मोबाइल बोर्ड गेम, Claude के साथ कैसे बनाया, या हर चीज़ जिसे मैं शिप करता हूँ उसके पीछे की ROI सोच के लिए मैं कैसे तय करता हूँ कि कोई ऑटोमेशन बनाने लायक है या नहीं।