सब कुछ कोड के रूप में: एक monorepo से कंपनी चलाने का तरीका

 (kasava.dev)
3 पॉइंट द्वारा GN⁺ 2026-01-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Kasava उत्पाद विकास की पूरी प्रक्रिया को एक monorepo के भीतर मैनेज करता है, जहाँ code, documentation, marketing और operations data सब एकीकृत हैं
  • हर बदलाव single commit में लागू होता है, जिससे backend, frontend, website और documentation एक साथ अपडेट होते हैं
  • AI tools सीधे code, documentation और website को रेफ़र करके consistency validation, automatic documentation updates और content review जैसे काम करते हैं
  • CLAUDE.md, Selective CI/CD, independent npm project structure आदि के ज़रिए बड़े repository की complexity को न्यूनतम रखा जाता है
  • यह approach AI-native development culture को मज़बूत करता है और product, content व operations की सीमाएँ हटाकर तेज़ deployment और collaboration संभव बनाता है

AI-native development और monorepo का महत्व

  • Kasava सभी platform components को एक Git repository में एकीकृत करता है, जिसमें सिर्फ code ही नहीं बल्कि documentation, marketing, email और investor materials भी शामिल हैं
    • उदाहरण: frontend/, backend/, website/, docs/, marketing/, external/ आदि, कुल 5,470 से अधिक TypeScript files
  • AI code और documentation दोनों तक एक साथ पहुँचकर context-based automation करता है
    • documentation edits, website pricing changes और blog validation जैसे काम AI के साथ एक ही conversation में हो जाते हैं
  • सभी बदलाव एक ही Git workflow(git push) से deploy होते हैं
    • code, content, documentation और marketing सभी एक ही review, CI/CD और audit process से गुजरते हैं
  • यह तरीका speed और consistency बढ़ाता है और “सब कुछ कोड के रूप में मैनेज करने” की संस्कृति स्थापित करता है

एक repository में एकीकरण क्यों

  • सीमाओं के पार atomic changes
    • backend API बदलने पर frontend type definitions और documentation उसी commit में अपडेट हो जाते हैं
    • उदाहरण: Asana integration feature जोड़ते समय backend, frontend, documentation और website एक ही PR में merge हुए
  • Single Source of Truth
    • billing-plans.json एकमात्र फ़ाइल के रूप में pricing limits को define करता है, और सभी services उसी को रेफ़र करती हैं
    • AI backend, frontend और website के बीच consistency को अपने आप validate करता है
  • cross-project refactoring
    • IDE में पूरे code, documentation और यहाँ तक कि blog examples तक search और edit किए जा सकते हैं
  • shared tools और pipelines
    • common CI/CD, dependencies और search environment से management सरल होता है

repository structure और components

  • Core Application:
    • frontend/ Next.js 16 + React 19 पर आधारित है, और backend/ Cloudflare Workers + Hono + Mastra का उपयोग करता है
    • API changes के समय type safety और test utilities साझा किए जाते हैं
  • Marketing:
    • इसमें website/, marketing/blogs/, investor-deck/, email/ शामिल हैं
    • blog, email और investor materials सभी code के रूप में version control में रहते हैं, और git revert से rollback संभव है
  • Documentation:
    • docs/ Mintlify-आधारित public documentation है, जबकि docs-internal/ internal architecture documentation है
    • code के साथ searchable होने से wiki की जगह हमेशा up-to-date जानकारी बनी रहती है
  • External Services:
    • इसमें Chrome extension, Google Docs Add-on, GCP Functions जैसी external deployment services शामिल हैं
    • API contracts साझा होने से बदलाव होने पर सब जगह एक साथ अपडेट संभव है
  • Development Infrastructure:
    • github-simulator/, infra-tester/, scripts/ आदि में local development के लिए mock servers और test tools शामिल हैं

संचालन का तरीका और development culture

  • workspace का उपयोग नहीं
    • हर directory को independent npm project के रूप में रखा जाता है, जिससे dependency conflicts से बचाव होता है
  • Selective CI/CD
    • GitHub Actions path-based triggers के ज़रिए केवल संबंधित tests चलाता है
  • CLAUDE.md rules
    • हर प्रमुख directory में tech stack, commands और architecture decisions documented रहते हैं
    • AI assistant इन्हें पढ़कर project context समझता है
  • consistent tool configuration
    • .prettierrc, .eslintrc, tsconfig.json जैसी common settings बनाए रखी जाती हैं

चुनौतियाँ और समाधान

  • repository size: अभी clone time लगभग 20 सेकंड है, और Git performance में कोई समस्या नहीं है
    • बड़े assets को अलग करके R2/S3 में रखने की योजना है
  • build time: हर project स्वतंत्र रूप से build होता है, और Turbopack, Wrangler, WXT से तेज़ rebuild संभव है
  • permission boundaries: छोटी टीम में सभी को full access दिया जा सकता है, और ज़रूरत पड़ने पर CODEOWNERS व branch protection लागू किए जा सकते हैं
  • context switching: अलग-अलग भाषाओं(TypeScript, Apps Script, MJML) के बीच स्विच करना CLAUDE.md और unified format से आसान बनाया जाता है

निष्कर्ष

  • Kasava का monorepo सिर्फ एक trend नहीं, बल्कि context integration के ज़रिए productivity को अधिकतम करने का साधन है
  • backend, frontend, documentation और marketing एक ही बदलाव के साथ चलते हैं, और AI इन्हें real time में validate करता है
  • नतीजतन, “monorepo कोई बाधा नहीं बल्कि एक force multiplier” की तरह काम करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-01
Hacker News की राय

  • यह पूरी कंपनी को मैनेज करना नहीं, बल्कि बस एक प्रोडक्ट (monorepo) जैसा लगता है
    इसमें finance, HR, contracts, team photos जैसी चीज़ें नहीं हैं; बस frontend+backend structure है, जिसमें marketing folder थोड़ा अलग तरीके से शामिल है

    • लिंक किए गए लेख को देखें तो पता चलता है कि यह कंपनी असल में one-person company है
      इसलिए सब कुछ एक repo में डालना संभव है, लेकिन ऐसी स्थिति में इससे मिलने वाले “insight” की वैल्यू पर सवाल उठता है
    • “AI! AI!”
    • repo में infrastructure code (IaC) भी शामिल नहीं है
    • मैं ऐसा उदाहरण देखना चाहूँगा जहाँ सचमुच सब कुछ GitHub repo के अंदर हो
      जैसे encrypted artifacts भी शामिल हों, और “encryption key सिर्फ CEO के पास physically हो” जैसी व्यवस्था हो
      अच्छा होता अगर GitHub private folder की concept जोड़ता, लेकिन वह ACL का मामला है, इसलिए शायद यह ज़रूरत से ज़्यादा मांग है

  • मैं monorepo और no development branch दर्शन का समर्थक हूँ
    लेकिन development और release अलग होने चाहिए
    stable release cut करके cherry-pick कर पाना चाहिए, और frontend व backend के बीच API stability हर हाल में बनी रहनी चाहिए

    • कुछ लोगों ने पूछा कि “no development branch” का मतलब क्या है
      अगर main branch पर सीधे development किया जाए, तो अलग-अलग आकार के कामों को साथ में कैसे मैनेज किया जाता है, यह जानना चाहा गया
    • कुछ लोगों ने यह भी पूछा कि cherry-pick की ज़रूरत पड़ने का ठोस उदाहरण क्या है
      उनका कहना था कि वे 3 से ज़्यादा products को monorepo में चला रहे हैं, और stable release unit के हिसाब से deploy करने पर भी कोई समस्या नहीं हुई
    • किसी ने कहा कि वे feature flag से deployment timing control करते हैं
    • एक अन्य व्यक्ति ने कहा कि उसे लंबे समय तक branches बनाए रखना पसंद है
      वह git squash को पसंद नहीं करता, और कहता है कि forking approach developers को ज़्यादा आज़ादी देती है

  • “एक बदलाव से हर जगह एक साथ update हो जाता है” वाली बात खतरनाक भ्रम है
    DB या API वाले systems में हमेशा backward compatibility का ध्यान रखना पड़ता है
    कई teams वाली organization में अक्सर ऐसा होता है कि एक team upgrade validate नहीं कर पाती और पूरा काम रुक जाता है
    इसलिए gradual rollout ज़रूरी है

    • पूरी तरह सहमत। छोटी कंपनी (Kasava) में यह चल सकता है, लेकिन global SaaS में कुछ मिनट का downtime भी घातक होता है
      monorepo अपने आप में बुरा नहीं है, लेकिन “एक बदलाव से सब कुछ तुरंत deploy हो जाता है” संभव नहीं है
      क्योंकि DB schema और code एक साथ नहीं बदल सकते
      ऐसी पोस्ट AI द्वारा लिखे ब्लॉग जैसी लगती है, और लगता है कि शायद असली customers भी बहुत कम होंगे
    • इसका जवाब यह भी था कि code कहाँ store है (repo) और deployment कैसे होता है, ये अलग चीज़ें होनी चाहिए
      organization की समस्या को technical problem समझने के बजाय, inter-team policy और leadership से उसे coordinate करना चाहिए
    • किसी ने कहा कि वे monorepo और automatic code generation (openapi-generator) का इस्तेमाल करके services के बीच API changes को तुरंत reflect कर देते हैं
      साथ ही यह भी जोड़ा कि यह तरीका छोटी team होने पर ही संभव है
    • “AI context को एक जगह इकट्ठा करना ताकत है” इस बात पर किसी ने कहा कि कई repos को workspace के रूप में clone कर लेना भी पर्याप्त है
    • इसके उलट, किसी ने कहा कि उससे भी बुरी स्थिति वह है जहाँ हर service अपना version बनाए रखती है और update ही नहीं करती

  • पहले मुझे monorepo पसंद नहीं था, लेकिन Claude Code इस्तेमाल करने के बाद मेरी राय बदल गई
    जब frontend और backend एक ही repo में हों तो sync करना आसान होता है

    • किसी ने कहा कि parent directory से Claude खोलो तो भी ठीक चलता है, लेकिन एक ही commit में दोनों तरफ बदलाव कर पाना अच्छी बात है
    • किसी ने प्रतिक्रिया दी कि “अगर monorepo इस्तेमाल करने की वजह सिर्फ command flags कम करना है, तो यह थोड़ा मज़ाकिया है”
    • मैंने भी कई LLM tools को जोड़ना मुश्किल पाया, इसलिए monorepo में refactor किया
    • React Native के hoisting issue की वजह से yarn workspace से बचते हैं, लेकिन PRD या planning documents को repo में रखना AI context देने में उपयोगी था
    • Claude Code वास्तव में कई directories को एक साथ संभाल सकता है, इसलिए monorepo अनिवार्य नहीं है

  • यह लेख AI द्वारा लिखा हुआ महसूस होता है
    इंसानों द्वारा लिखी सामग्री ढूँढना मुश्किल होता जा रहा है, और यह थका देने वाला है

    • GPTZero से जाँचने पर लगभग सब कुछ AI-generated लगता है
      “This isn’t just for…”, “The Challenges (And How We Handle Them)” जैसी पंक्तियाँ典型 AI लहजा लगती हैं
    • इसके विपरीत, किसी ने कहा कि “AI लेखन की शिकायतें सुन-सुनकर भी थकान होती है”
      मतलब, भले परफेक्ट न हो, क्या यह इंसानों के लिखे लेख से बेहतर नहीं है?

  • “Claude से pricing page update करने को कहना” वाला हिस्सा अजीब लगा
    जब marketing page उसी repo में manage हो रहा है, और काम सिर्फ config file के data को पढ़कर भी हो सकता है, तो उसे LLM को सौंपना समझ नहीं आता

    • किसी ने कहा कि AI अब लत या निर्भरता में बदल रहा है
    • इसके जवाब में किसी ने कहा कि “code review अभी भी मौजूद है”
      यानी AI होने का मतलब यह नहीं कि इंसान review नहीं करते

  • “frontend, backend, website” को एक ही repo में डालना उलझाने वाला लगता है
    commit-level integration अच्छी लगती है, लेकिन 3 repos से भी इसे ठीक से manage किया जा सकता है
    monorepo को सही तरीके से चलाने के लिए maintenance cost काफ़ी ज़्यादा होती है

  • लेख भले AI द्वारा लिखा हुआ लगे, लेकिन IaC को चरम तक बढ़ाने वाला विचार अपने आप में दिलचस्प है
    इसलिए इस पर मिश्रित भावनाएँ हैं

    • यह देखकर हैरानी हुई कि ज़्यादातर comments AI-writing के संकेत पहचान नहीं पाए
      आगे चलकर जब ऐसी LLM style आम हो जाएगी, तो आज के ऐसे लेख शायद पुराने या भद्दे लगेंगे
    • किसी ने कहा कि कम से कम “Why This Matters” जैसी अभिव्यक्तियाँ तो बदलनी चाहिए थीं
    • किसी ने यह भी कहा कि AI उपयोग का खुलासा किए बिना इंसानी नाम से पोस्ट करना बौद्धिक बेईमानी जैसा लगता है

  • अगर कंपनी website उसी repo में हो, तो branding material और tone आसानी से मिल जाते हैं
    इसलिए customer-facing slides या demo videos को automatically generate करना आसान हो सकता है
    आगे बढ़कर documents, bugs, issues तक को एक ही जगह रखना भी दिलचस्प है

  • पुराने startup Pangea में हमने ऐसा ही ढाँचा बनाया था
    कुल मिलाकर अच्छा था, लेकिन परफेक्ट नहीं

    • सब कुछ repo से manage करने की कोशिश में feature flag changes धीमे हो गए, और branch immutability को manage करना मुश्किल था
    • जब services की संख्या लगभग 20 हुई, तो GitLab CI धीमा और जटिल हो गया
    • E2E tests धीमे और unstable थे, इसलिए pipeline अक्सर टूट जाती थी
      फिर भी ARM पर migrate करके computing cost में 70% की कटौती जैसी उपलब्धियाँ मिलीं
      Pangea लिंक
    • इस पर किसी ने पूछा कि क्या turbo, buck, Bazel जैसे monorepo tools इस्तेमाल किए गए थे
      उनका कहना था कि ऐसे tools के बिना CI scalability की सीमा जल्दी सामने आ जाती है