El problema
En Chile, la administración de condominios sigue funcionando con planillas Excel, grupos de WhatsApp y trámites en papel. El cobro de gastos comunes, la conciliación de comprobantes de pago, los comunicados, el control de encomiendas, los certificados de residencia y el cierre contable mensual viven en herramientas desconectadas entre sí. El resultado es trabajo manual repetido, errores de cuadratura y cero trazabilidad frente a un reclamo.
ConAdmin centraliza toda esa operación en una sola plataforma, con un portal para el administrador, una app móvil para los residentes y cumplimiento de la normativa chilena de protección de datos.
La decisión técnica central: aislamiento en la base de datos
ConAdmin es multi-tenant: muchas comunidades comparten una misma base de datos. El riesgo evidente de ese modelo es que una consulta mal escrita filtre datos de un cliente a otro.
En vez de confiar ese aislamiento a la lógica de aplicación —donde basta un
WHERE olvidado para causar una brecha—, ConAdmin lo delega al motor de
base de datos con Row-Level Security de PostgreSQL. La aplicación
corre con un rol de Postgres sin privilegios y cada consulta queda acotada al tenant
activo por política del propio motor. Aunque un endpoint tuviera un bug, la base de
datos no devuelve filas de otro cliente.
Esa decisión convierte un problema disperso por todo el código en un único punto de control: autenticación y fijación del contexto de tenant. Es también la restricción que ordena el resto de la arquitectura.
Arquitectura
El backend es un monolito modular en capas con separación estricta:
routes/ (endpoints y HTTP), schemas/ (contratos validados
con Pydantic), services/ (reglas de negocio, agnósticas al transporte) y
models.py (ORM). Cada capa conoce solo a la inmediatamente inferior.
El beneficio concreto: los mismos servicios de dominio alimentan el portal web, la app
móvil y un worker en segundo plano que genera boletas, sin duplicar reglas de negocio.
Y como los servicios no dependen de HTTP, la lógica crítica —cálculo financiero,
cierres mensuales, auditoría, corte de acceso al portal— se prueba directamente con
pytest.
Sobre esa base: ~90 endpoints REST, 18 entidades de dominio, migraciones versionadas con Alembic y backend contenedorizado con Docker.
Funcionalidad destacada
- Gestión financiera — ingresos y egresos, cargos por propiedad, generación automática de boletas, cierres contables mensuales reversibles e informes exportables a PDF y Excel.
- Conciliación de pagos — el residente sube su comprobante desde el celular; el administrador revisa y aprueba.
- IA aplicada con criterio — extracción automática de campos desde imágenes y PDFs de comprobantes para pre-llenar formularios, y redacción asistida de comunicados. La IA sugiere, la persona confirma: nunca escribe datos financieros sin revisión humana.
- Portal y app de residentes — estado de cuenta, comunicados, encomiendas y certificados, con notificaciones push y corte automático de acceso al dar de baja a un residente.
- Conserjería — control de encomiendas y operación de turno.
Cumplimiento normativo (Ley 21.719)
El sistema maneja datos personales de residentes, así que el cumplimiento no fue un anexo sino parte del diseño. Se implementaron y documentaron por fases: minimización y almacenamiento seguro, gestión de consentimiento, ejercicio de derechos del titular (acceso, rectificación, supresión), auditoría de accesos y operaciones con informe exportable, políticas de retención y eliminación, y una evaluación de impacto (DPIA).
Qué demuestra este proyecto
Producto pensado desde un problema real de mercado y llevado hasta una plataforma funcional en producción: diseño de arquitectura multi-tenant segura, backend en capas y testeado, tres clientes distintos sobre una misma API (web, móvil y worker), integración de IA con un criterio de riesgo definido y cumplimiento normativo documentado. Todo el ciclo —producto, desarrollo, despliegue— ejecutado de forma individual.