Convivia

The detailed case study is available in Spanish.

Logros

• 8 módulos entregados, del bootstrap al despliegue del MVP
• Aislamiento entre organizaciones con RLS en PostgreSQL 16
• UAT propio: 14 defectos detectados y priorizados por gravedad
• 12 pull requests revisados y mergeados, sin auto-merge

Contexto

Convivia es un proyecto propio, iniciado desde cero el 15 de septiembre de 2026. Es una plataforma PropTech que reúne en un solo sistema el ciclo de vida de un inmueble residencial: organizaciones, comunidades, edificios y unidades; propietarios, inquilinos y residentes; contratos de alquiler; facturas, cobros y pagos; incidencias con órdenes de trabajo a profesionales; y comunicados a los residentes.

Está pensada para administradores de fincas, propietarios e inquilinos. Como varias organizaciones comparten la misma plataforma, el requisito central es que los datos de una nunca aparezcan en otra.

Mi rol

Trabajo como product owner y autoridad de aceptación y despliegue. La implementación la realizan tres agentes de IA con responsabilidades separadas: arquitectura y aceptación, backend y persistencia, y frontend y pruebas end-to-end.

• Fijo los objetivos del producto en una hoja de ruta por entregables.
• Decido cómo se entrega: un pull request por tarea, sin auto-merge. Ningún agente aprueba su propio trabajo.
• Reviso y mergeo los cambios.
• Ejecuto yo las pruebas de aceptación y redacto el informe de defectos.
• Despliego y compruebo la aplicación en mi servidor Ubuntu.
• Me reservo las decisiones de riesgo: los agentes no pueden recrear la base de datos ni activar Docker en desarrollo sin mi confirmación expresa.

Qué construí

Plataforma y módulos de negocio

Ocho objetivos funcionales entregados sobre un bootstrap inicial: autenticación y sesiones; organizaciones y membresías; comunidades, edificios y unidades; ocupación y contratos; incidencias y órdenes de trabajo; facturación, pagos y libro contable; panel por rol con tablón de anuncios; y el paquete de despliegue del MVP. La interfaz es bilingüe, en español e inglés.

La arquitectura es un monolito modular en un monorepo, con la API y la web separadas y paquetes compartidos de contratos, base de datos y pruebas.

• Navegador (React) → API REST (Fastify) → validación con contratos Zod compartidos → transacción con la organización fijada → PostgreSQL 16 con RLS

Aislamiento multi-tenant en la base de datos

Cada petición abre una transacción con la organización fijada, y PostgreSQL aplica seguridad a nivel de fila (Row-Level Security) en las tablas de negocio. Aunque el código olvide un filtro, la base de datos no devuelve datos ajenos. El acceso a un recurso de otra organización responde 404, no 403, para no revelar que existe.

Las contraseñas se guardan con scrypt y sal por usuario, y las sesiones usan cookies HttpOnly.

Gobernanza de agentes de IA y calidad

Las reglas del proyecto están escritas en el propio repositorio: qué puede hacer cada agente, qué exige una decisión documentada (ADR) y qué está prohibido, como tocar la seguridad de la base de datos o el CI para que una build pase.

• Ramas con nombre por objetivo y agente, y reclamo de tareas por issue para evitar trabajo duplicado.
• CI en GitHub Actions con 4 jobs: lint y tipos, tests unitarios, tests de integración contra PostgreSQL real y build de producción con pruebas end-to-end.
• 35 ficheros de test, 10 especificaciones BDD, 5 ADRs y 9 migraciones versionadas.

Defecto de pagos detectado en aceptación

En las pruebas de aceptación registré varios pagos sobre una factura de 1.100 € y el sistema los aceptó todos: la factura acabó con 2.100 € cobrados. La causa era que el pago se insertaba antes de validarse contra el saldo pendiente, y el formulario proponía el total de la factura en lugar de lo que quedaba por pagar.

La corrección, pendiente de integrar, valida antes de escribir: un pago de importe cero o negativo, mayor que el saldo pendiente o sobre una factura pagada o cancelada se rechaza. Las pruebas de regresión fijan los límites: con un saldo de 600,00 € se acepta un pago de 600,00 € y se rechaza uno de 600,01 €.

Despliegue en servidor propio

La aplicación corre en mi servidor Ubuntu con Docker Compose, en tres contenedores: API, web y PostgreSQL, con la base de datos en un volumen persistente. Incluye sondas de salud (la de disponibilidad comprueba la base de datos), logs JSON estructurados y scripts de backup y restauración.

Resultado

• 8 objetivos funcionales entregados entre el 15 y el 22 de septiembre de 2026.
• Aplicación desplegada en un subdominio propio y respondiendo en producción.
• Informe de aceptación con 14 defectos, convertido en un plan de corrección de 5 tareas priorizadas por gravedad.
• Los dos defectos críticos, la validación de pagos y la build de las imágenes Docker, tienen corrección en revisión.
• Convivia funciona con datos de demostración: todavía no tiene usuarios ni cobros reales, ni pasarela de pago.

Qué demuestra

• Dirigir desarrollo con agentes de IA con reglas escritas, revisión humana y trazabilidad.
• Diseñar seguridad multi-tenant en la capa de datos, no solo en la aplicación.
• Encontrar defectos de negocio en pruebas de aceptación y priorizarlos por gravedad.
• Llevar un producto de cero a un servidor propio con Docker, CI y documentación.

Nota

El repositorio es privado: el código, la documentación técnica y el historial de pull requests pueden revisarse en entrevista. La demo usa organizaciones y cuentas ficticias.