- Kasava gestiona todo el proceso de desarrollo del producto dentro de un solo monorepo, integrando código, documentación, marketing y datos operativos
- Todos los cambios se reflejan en un único commit, de modo que el backend, frontend, sitio web y documentación se actualizan al mismo tiempo
- Las herramientas de IA consultan directamente el código, la documentación y el sitio web para realizar validaciones de consistencia, actualizaciones automáticas de documentación y revisión de contenido
- Con CLAUDE.md, CI/CD selectivo y una estructura de proyectos npm independientes, minimizan la complejidad de un repositorio grande
- Este enfoque fortalece una cultura de desarrollo AI-native y elimina las fronteras entre producto, contenido y operaciones para permitir despliegues rápidos y colaboración ágil
El significado del desarrollo AI-native y del monorepo
- Kasava integra todos los componentes de su plataforma en un solo repositorio Git, incluyendo no solo código sino también documentación, marketing, correos electrónicos y materiales para inversionistas
- Ejemplo:
frontend/, backend/, website/, docs/, marketing/, external/, entre otros, con más de 5,470 archivos TypeScript
- La IA puede acceder al código y a la documentación al mismo tiempo para realizar automatización basada en contexto
- Cambios en documentación, ajustes de precios en el sitio web y validación de blogs se resuelven dentro de una sola conversación con la IA
- Todos los cambios se despliegan con el mismo flujo de trabajo de Git (
git push)
- Código, contenido, documentación y marketing pasan por los mismos procesos de revisión, CI/CD y auditoría
- Este método mejora la velocidad y la consistencia y consolida una cultura de “gestionar todo como código”
Por qué unificar todo en un solo repositorio
- Cambios atómicos entre fronteras (Atomic Changes)
- Cuando se modifica una API del backend, las definiciones de tipos del frontend y la documentación se actualizan en el mismo commit
- Ejemplo: al añadir una integración con Asana, backend, frontend, documentación y sitio web se fusionan en un solo PR
- Fuente única de verdad (Single Source of Truth)
- Un solo
billing-plans.json define los límites de los planes, y todos los servicios lo consultan
- La IA verifica automáticamente la consistencia entre backend, frontend y sitio web
- Refactorización entre proyectos
- Desde el IDE se puede buscar y modificar todo el código, la documentación e incluso ejemplos en blogs
- Herramientas y pipelines compartidos
- La gestión se simplifica con CI/CD común, dependencias compartidas y un entorno de búsqueda unificado
Estructura del repositorio y sus componentes
- Core Application:
frontend/ está basado en Next.js 16 + React 19, y backend/ usa Cloudflare Workers + Hono + Mastra- Cuando cambia una API, se comparten la seguridad de tipos y las utilidades de prueba
- Marketing:
- Incluye
website/, marketing/blogs/, investor-deck/, email/
- Blogs, correos y materiales para inversionistas se gestionan con control de versiones como código, y pueden revertirse con
git revert
- Documentation:
docs/ es documentación pública basada en Mintlify, y docs-internal/ contiene documentación interna de arquitectura- Puede buscarse junto con el código y se mantiene actualizada en tiempo real en lugar de depender de una wiki
- External Services:
- Incluye servicios desplegados externamente como extensión de Chrome, add-on de Google Docs y funciones de GCP
- Al compartir contratos de API, los cambios se reflejan al mismo tiempo
- Development Infrastructure:
- Incluye servidores simulados y herramientas de prueba para desarrollo local como
github-simulator/, infra-tester/, scripts/
Forma de operación y cultura de desarrollo
- Sin workspaces
- Cada directorio se mantiene como un proyecto npm independiente para evitar conflictos de dependencias
- CI/CD selectivo (Selective CI/CD)
- GitHub Actions se activa según rutas y ejecuta solo las pruebas relacionadas
- Reglas en CLAUDE.md
- En cada directorio principal se documentan el stack técnico, los comandos y las decisiones de arquitectura
- El asistente de IA lo lee para entender el contexto del proyecto
- Configuración de herramientas consistente
- Se mantienen configuraciones comunes como
.prettierrc, .eslintrc, tsconfig.json
Retos y respuesta
- Tamaño del repositorio: el tiempo actual de clonación es de unos 20 segundos, sin problemas de rendimiento en Git
- Los activos pesados se separarán a R2/S3
- Tiempo de build: cada proyecto se compila de forma independiente, con reconstrucciones rápidas gracias a Turbopack, Wrangler y WXT
- Límites de permisos: los equipos pequeños pueden tener acceso completo, y si hace falta se pueden aplicar CODEOWNERS y protección de ramas
- Cambio de contexto: el cambio entre varios lenguajes (TypeScript, Apps Script, MJML) se alivia con CLAUDE.md y un formato unificado
Conclusión
- El monorepo de Kasava no es solo una tendencia, sino una herramienta para maximizar la productividad mediante la integración de contexto
- Backend, frontend, documentación y marketing funcionan como un solo cambio, y la IA lo valida en tiempo real
- Como resultado, “el monorepo no es una restricción, sino un acelerador (force multiplier)”
1 comentarios
Opiniones de Hacker News
Esto no parece administrar toda una empresa, sino más bien un solo producto (monorepo)
No hay finanzas, RR. HH., contratos ni fotos del equipo; solo una estructura de frontend+backend con una carpeta de marketing algo inusual
Por eso es posible meter todo en un solo repo, pero eso hace cuestionar el valor de los “insights” que se pueden sacar de una situación así
Por ejemplo, incluso artefactos cifrados, con algo como que “solo el CEO tenga físicamente la clave de cifrado”
Estaría bien que GitHub agregara el concepto de carpetas privadas, aunque quizá eso ya sería pedir demasiado por el tema de ACL
Yo sí apoyo la filosofía de monorepo y sin rama de desarrollo
Pero desarrollo y release deberían estar separados
Debería poder cortarse una release estable y hacer cherry-pick, y la estabilidad de la API entre frontend y backend tiene que mantenerse sí o sí
Si se desarrolla directamente en la rama principal, le intriga cómo gestionan en paralelo trabajos de distintos tamaños
Dice que opera más de 3 productos en un monorepo y que nunca tuvo problemas desplegando por unidades de release estables
No le gusta hacer git squash, y afirma que el modelo de forking da a los desarrolladores un entorno con más libertad
La idea de que “con un solo cambio todo se actualiza al mismo tiempo” es una ilusión peligrosa
En sistemas con BD o API, siempre hay que pensar en la compatibilidad hacia atrás
En organizaciones con varios equipos, puede pasar que un equipo no logre validar una actualización y termine frenando a todos los demás
Por eso el rollout gradual es indispensable
El monorepo en sí no está mal, pero eso de que “con un solo cambio todo se despliega de inmediato” no es posible
Porque el esquema de la BD y el código no pueden cambiar al mismo tiempo
Este tipo de textos parecen blogs escritos por IA, y da la impresión de que casi no tienen clientes reales
Que no hay que confundir problemas organizacionales con problemas técnicos, y que eso debe coordinarse con políticas entre equipos y liderazgo
Agregó que es un enfoque viable porque se trata de un equipo pequeño
Antes no me gustaban los monorepos, pero cambié de opinión usando Claude Code
Si el frontend y el backend están en un solo repo, sincronizarlos es mucho más fácil
Este texto se siente como si lo hubiera escrito una IA
Cansa lo difícil que se está volviendo encontrar contenido escrito por humanos
Frases como “This isn’t just for…” o “The Challenges (And How We Handle Them)” son un tono típico de IA
Como diciendo: aunque no sea perfecto, ¿acaso no es mejor que muchos textos escritos por humanos?
La parte donde dice que “le pide a Claude que actualice la página de precios” suena extraña
Si administran la página de marketing en el mismo repo, cuesta entender por qué le delegarían eso a un LLM cuando bastaría con leer los datos de un archivo de configuración
O sea, que tener IA no significa que los humanos ya no revisen nada
Meter “frontend, backend y sitio web” en un solo repo resulta confuso
Integrarlo todo al nivel de commit suena bien, pero con 3 repos también se puede gestionar perfectamente
Operar un monorepo de verdad implica un costo de mantenimiento considerable
El texto parece escrito por IA, pero la idea de llevar IaC al extremo sí resulta interesante
Por eso genera sentimientos encontrados
Si en el futuro este estilo de LLM se vuelve normal para el público, probablemente los textos de ahora se verán anticuados
Tener el sitio web de la empresa en el mismo repo facilita encontrar material de branding y tono de comunicación
Por eso sería útil para generar automáticamente presentaciones para clientes o videos de demo
Incluso resulta interesante meter allí también documentación, bugs e issues
En la startup Pangea antes armaron una estructura parecida
En general funcionó bien, aunque no era perfecta
Aun así, también lograron resultados como migrar a ARM y reducir 70% los costos de cómputo
Enlace de Pangea
Dice que sin ese tipo de herramientas, CI termina chocando con límites de escalabilidad