Tres repos, una promesa

Tres modos en el producto; tres repos en el código. No es coincidencia. Es el mismo instinto aplicado dos veces: separar las cosas que se mueven a velocidades distintas.

El contexto

La tentación del monorepo es real. Un solo clone, un solo issue tracker, un solo CI. Hay empresas que lo hacen bien. Para un solo dev, el monorepo también tiene una ventaja: atomic refactor. Puedes cambiar una API y su consumo en el mismo PR.

Pero acopla caídas. Si el backend y el frontend viven en el mismo repo, también sus releases. Cuando quiero desplegar una micro-mejora del frontend, me leo también una migración de base de datos en la misma rama. Y cuando tengo prisa, me salto uno de los dos.

La decisión

Tres repositorios separados, una promesa compartida:

• camperroute-api. Backend FastAPI + Postgres + Celery. Ciclo propio. Desplegamos con un PR + merge a staging y otro a main. Ningún otro repo lo para.
• camperroute-app. Frontend React + Vite + PWA. También ciclo propio. El mismo patrón trunk-staging. Consume la API por contrato OpenAPI, no por imports directos.
• camperroute-meta. Privado. Contiene la documentación BMAD: briefs, epics, stories, arquitecturas, retros. No desplegamos nada — es el cuaderno de bitácora. Privado porque no es para consumidores, no porque sea secreto.

Por qué meta es privado. No contiene secretos ni datos sensibles. Contiene el cómo se toman las decisiones: dudas por resolver, errores cometidos, retros honestas. Si lo pusiera público, tendría que autocensurar — y un documento de desarrollo autocensurado vale cero. Mantenerlo privado me permite escribirlo como lo pensaría.

Qué no es

Para ser explícito:

• No es una arquitectura de microservicios. Hay un backend y un frontend. La separación es por repo, no por servicio en runtime.
• No son tres equipos. Soy uno. La separación no refleja una estructura organizativa; refleja ciclos de vida distintos.
• No es un manifiesto contra los monorepos. Para equipos de más de 2-3 personas con refactors cruzados frecuentes, un monorepo bueno (Nx, Turborepo, Bazel) probablemente compensa. Aquí, no.

Lo que viene

En el próximo — y último — post de la serie: cómo observo qué pasa en el producto sin ver al usuario. Sentry, sí, pero con las reglas de scrubbing de los paranoicos. La diferencia entre saber que algo se ha roto y saber a quién se le ha roto.