Semua Menjadi Kode: Cara Menjalankan Perusahaan dengan Satu Monorepo

 (kasava.dev)
3 poin oleh GN⁺ 2026-01-01 | 1 komentar | Bagikan ke WhatsApp
  • Kasava mengelola seluruh proses pengembangan produk di dalam satu monorepo, menyatukan kode, dokumentasi, pemasaran, dan data operasional
  • Semua perubahan diterapkan dalam satu commit, sehingga backend, frontend, situs web, dan dokumentasi diperbarui secara bersamaan
  • Alat AI langsung merujuk ke kode, dokumentasi, dan situs web untuk melakukan verifikasi konsistensi, pembaruan dokumentasi otomatis, dan peninjauan konten
  • CLAUDE.md, Selective CI/CD, dan struktur proyek npm independen digunakan untuk meminimalkan kompleksitas repositori berskala besar
  • Pendekatan ini memperkuat budaya pengembangan AI-native dan menghilangkan batas antara produk, konten, dan operasi sehingga memungkinkan deployment dan kolaborasi yang cepat

Makna pengembangan AI-native dan monorepo

  • Kasava mengintegrasikan semua komponen platform ke dalam satu repositori Git, mencakup bukan hanya kode tetapi juga dokumentasi, pemasaran, email, hingga materi investor
    • Contoh: terdiri dari lebih dari 5.470 file TypeScript seperti frontend/, backend/, website/, docs/, marketing/, external/
  • AI dapat mengakses kode dan dokumentasi sekaligus untuk melakukan otomatisasi berbasis konteks
    • Revisi dokumentasi, perubahan harga di situs web, dan verifikasi blog dapat ditangani dalam satu percakapan AI
  • Semua perubahan dideploy dengan workflow Git yang sama (git push)
    • Kode, konten, dokumentasi, dan pemasaran melewati proses review, CI/CD, dan audit yang sama
  • Cara ini meningkatkan kecepatan dan konsistensi serta menanamkan budaya “mengelola semuanya sebagai kode”

Alasan menyatukan semuanya dalam satu repositori

  • Atomic changes lintas batas
    • Saat API backend diubah, definisi tipe frontend dan dokumentasi diperbarui dalam commit yang sama
    • Contoh: saat menambahkan integrasi Asana, backend, frontend, dokumentasi, dan situs web digabung dalam satu PR
  • Single source of truth
    • Satu billing-plans.json mendefinisikan batas paket harga dan semua layanan merujuk padanya
    • AI secara otomatis memverifikasi konsistensi antara backend, frontend, dan situs web
  • Refactoring lintas proyek
    • Di IDE, seluruh kode, dokumentasi, hingga contoh di blog dapat dicari dan diubah
  • Alat dan pipeline bersama
    • Pengelolaan disederhanakan lewat CI/CD, dependensi, dan lingkungan pencarian yang sama

Struktur repositori dan komponennya

  • Core Application:
    • frontend/ berbasis Next.js 16 + React 19, sedangkan backend/ menggunakan Cloudflare Workers + Hono + Mastra
    • Saat API berubah, stabilitas tipe dan utilitas pengujian dapat dibagikan
  • Marketing:
    • Mencakup website/, marketing/blogs/, investor-deck/, email/
    • Blog, email, dan materi investor semuanya dikelola versinya sebagai kode, dan dapat di-rollback dengan git revert
  • Documentation:
    • docs/ adalah dokumentasi publik berbasis Mintlify, docs-internal/ adalah dokumentasi arsitektur internal
    • Dapat ditelusuri bersama kode, menjaga informasi tetap terbaru secara real-time alih-alih memakai wiki
  • External Services:
    • Mencakup layanan eksternal yang dideploy seperti ekstensi Chrome, Google Docs Add-on, dan GCP Functions
    • Kontrak API dibagikan sehingga perubahan dapat diterapkan secara serentak
  • Development Infrastructure:
    • Mencakup server tiruan dan alat pengujian untuk pengembangan lokal seperti github-simulator/, infra-tester/, scripts/

Cara kerja operasional dan budaya pengembangan

  • Tidak menggunakan workspace
    • Setiap direktori dipertahankan sebagai proyek npm independen untuk mencegah konflik dependensi
  • Selective CI/CD
    • GitHub Actions dipicu berdasarkan path sehingga hanya pengujian terkait yang dijalankan
  • Aturan CLAUDE.md
    • Setiap direktori utama mendokumentasikan stack teknis, perintah, dan keputusan arsitektur
    • Asisten AI membacanya untuk memahami konteks proyek
  • Konfigurasi alat yang konsisten
    • Menjaga pengaturan bersama seperti .prettierrc, .eslintrc, tsconfig.json

Tantangan dan respons

  • Ukuran repositori: saat ini waktu clone sekitar 20 detik, tanpa masalah performa Git
    • Aset berukuran besar rencananya akan dipisahkan ke R2/S3
  • Waktu build: setiap proyek dibangun secara independen, dengan rebuild cepat melalui Turbopack, Wrangler, dan WXT
  • Batas izin akses: tim kecil dapat mengakses seluruhnya, dan bila perlu CODEOWNERS serta branch protection dapat diterapkan
  • Perpindahan konteks: perpindahan antarberbagai bahasa (TypeScript, Apps Script, MJML) diringankan dengan CLAUDE.md dan format yang seragam

Kesimpulan

  • Monorepo Kasava bukan sekadar tren, melainkan alat untuk memaksimalkan produktivitas melalui integrasi konteks
  • Backend, frontend, dokumentasi, dan pemasaran bergerak dalam satu perubahan, dan AI memverifikasinya secara real-time
  • Hasilnya, “monorepo bukan batasan melainkan perangkat akselerasi (force multiplier)”

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-01
Komentar Hacker News

  • Ini tampaknya bukan mengelola seluruh perusahaan, melainkan hanya satu produk (monorepo)
    Tidak ada hal seperti keuangan, HR, kontrak, atau foto tim; hanya struktur frontend+backend dengan folder pemasaran yang sedikit tidak biasa

    • Jika melihat artikel yang ditautkan, terlihat bahwa perusahaan ini pada dasarnya adalah perusahaan satu orang
      Jadi wajar jika semuanya bisa dimasukkan ke satu repo, tetapi nilai “insight” yang didapat dalam situasi seperti itu jadi patut dipertanyakan
    • “AI! AI!”
    • Di dalam repo juga tidak ada kode infrastruktur (IaC)
    • Saya ingin melihat contoh yang benar-benar menaruh segalanya ke dalam repo GitHub
      Misalnya sampai mencakup artefak terenkripsi, dengan model seperti “hanya CEO yang memegang kunci enkripsi secara fisik”
      Akan bagus jika GitHub menambahkan konsep private folder, tetapi itu menyangkut masalah ACL jadi mungkin tuntutan yang berlebihan

  • Saya mendukung filosofi monorepo dan no development branch
    Namun pengembangan dan rilis harus dibedakan
    Harus bisa memotong rilis stabil lalu melakukan cherry-pick, dan stabilitas API antara frontend dan backend wajib dijaga

    • Ada juga yang bertanya apa arti “no development branch”
      Jika pengembangan dilakukan langsung di branch utama, mereka penasaran bagaimana mengelola berbagai pekerjaan dengan skala berbeda secara paralel
    • Ada juga yang meminta contoh konkret kapan cherry-pick diperlukan
      Ia mengatakan dirinya mengelola lebih dari 3 produk dalam monorepo, dan tidak ada masalah meski deployment dilakukan per unit rilis stabil
    • Ada yang mengatakan mereka mengontrol waktu deployment dengan feature flag
    • Yang lain suka mempertahankan branch lama
      Ia tidak suka git squash, dan mengatakan pendekatan forking memberi lingkungan yang lebih bebas bagi developer

  • Pernyataan “satu perubahan memperbarui semua tempat sekaligus” adalah ilusi berbahaya
    Dalam sistem yang memiliki DB atau API, kompatibilitas ke belakang harus selalu dipertimbangkan
    Di organisasi dengan banyak tim, sering terjadi satu tim tidak bisa memvalidasi upgrade sehingga semuanya ikut terhambat
    Karena itu rollout bertahap adalah keharusan

    • Sangat setuju. Di perusahaan kecil (Kasava) ini mungkin baik-baik saja, tetapi di SaaS global bahkan beberapa menit downtime pun bisa fatal
      Monorepo itu sendiri tidak buruk, tetapi “semua langsung ter-deploy dengan satu perubahan” itu mustahil
      Karena skema DB dan kode tidak bisa berubah secara bersamaan
      Tulisan seperti ini terlihat seperti blog yang ditulis AI, dan sepertinya juga hampir tidak punya pelanggan sungguhan
    • Ada juga sanggahan bahwa lokasi penyimpanan kode (repo) dan cara deployment harus dipisahkan
      Jangan salah mengira masalah organisasi sebagai masalah teknis; ini harus diselaraskan lewat kebijakan antar tim dan kepemimpinan
    • Ada yang mengatakan mereka menggunakan monorepo dan code generation otomatis (openapi-generator) untuk langsung mencerminkan perubahan API antar layanan
      Ia menambahkan bahwa pendekatan seperti ini hanya mungkin untuk tim kecil
    • Menanggapi klaim bahwa “mengumpulkan konteks AI di satu tempat adalah kekuatan”, ada juga pendapat bahwa cukup meng-clone beberapa repo sebagai workspace
    • Sebaliknya, ada juga pendapat bahwa lebih buruk jika semua layanan mempertahankan versinya masing-masing dan tidak pernah diperbarui

  • Dulu saya tidak suka monorepo, tetapi setelah memakai Claude Code pandangan saya berubah
    Jika frontend dan backend ada dalam satu repo, sinkronisasi jadi mudah

    • Katanya meski membuka Claude dari direktori induk juga berjalan baik, tetap menyenangkan karena kedua sisi bisa diubah sekaligus dalam satu commit
    • Ada juga tanggapan, “kalau alasan memakai monorepo hanya untuk mengurangi flag perintah, itu agak lucu”
    • Saya juga pernah merombak ke monorepo karena sulit menghubungkan beberapa tool LLM
    • Karena masalah hoisting di React Native, mereka menghindari yarn workspace, tetapi menaruh PRD atau dokumen perencanaan di repo berguna untuk memberi konteks pada AI
    • Claude Code sebenarnya bisa menangani banyak direktori sekaligus, jadi monorepo tidak mutlak diperlukan

  • Tulisan ini terasa seperti ditulis AI
    Melelahkan karena sulit menemukan konten yang benar-benar ditulis manusia

    • Jika dicek dengan GPTZero, hampir semuanya tampak sebagai hasil AI
      Kalimat seperti “This isn’t just for...” dan “The Challenges (And How We Handle Them)” adalah gaya khas AI
    • Sebaliknya, ada juga pendapat bahwa “bosan juga terus mengeluh soal tulisan AI”
      Kurang lebih maksudnya, meski tidak sempurna bukankah ini tetap lebih baik daripada tulisan manusia

  • Bagian yang menyuruh “Claude untuk memperbarui halaman harga” terasa aneh
    Jika halaman pemasaran dikelola dalam repo yang sama, rasanya sulit memahami mengapa hal yang cukup dilakukan dengan membaca data dari file config justru diserahkan ke LLM

    • Ada yang menyoroti bahwa AI sedang berubah menjadi kecanduan atau ketergantungan
    • Ada juga bantahan bahwa “code review tetap ada”
      Maksudnya, keberadaan AI tidak berarti manusia tidak lagi melakukan peninjauan

  • Menaruh “frontend, backend, website” dalam satu repo terasa membingungkan
    Integrasi pada level commit memang terlihat bagus, tetapi 3 repo pun sudah cukup untuk mengelolanya
    Untuk menjalankan monorepo dengan benar, biaya pemeliharaannya cukup besar

  • Tulisan ini memang tampak seperti dibuat AI, tetapi gagasannya sendiri sebagai perluasan ekstrem dari IaC tetap menarik
    Karena itu rasanya campur aduk

    • Menarik juga bahwa sebagian besar komentar tidak menyadari nuansa tulisan AI itu
      Jika nanti gaya LLM seperti ini menjadi akrab bagi publik, tulisan-tulisan sekarang mungkin akan terasa kuno
    • Ada juga yang bilang setidaknya ungkapan seperti “Why This Matters” sebaiknya diganti
    • Ada pula yang merasa mengunggah tulisan dengan nama manusia tanpa menyebut penggunaan AI terasa seperti ketidakjujuran intelektual

  • Jika situs web perusahaan ada di repo yang sama, materi branding dan tone mudah ditemukan
    Karena itu lebih mudah untuk membuat slide atau video demo untuk pelanggan secara otomatis
    Lebih jauh lagi, menaruh dokumentasi, bug, dan issue di satu tempat juga terdengar menarik

  • Di startup lama Pangea, kami pernah membuat struktur serupa
    Secara umum bagus, tetapi tidak sempurna

    • Karena mencoba mengelola semuanya lewat repo, perubahan feature flag jadi lambat, dan sulit mengelola immutability branch
    • Saat jumlah layanan mencapai sekitar 20, GitLab CI menjadi lambat dan rumit
    • Pengujian E2E lambat dan tidak stabil, sehingga pipeline sering rusak
      Meski begitu, ada juga hasil seperti beralih ke ARM dan mengurangi biaya komputasi 70%
      Tautan Pangea
    • Menanggapi ini, ada juga yang bertanya apakah mereka memakai tool monorepo seperti turbo, buck, Bazel
      Katanya tanpa tool seperti itu, CI akan menabrak batas skalabilitas