en producción
Caso — Sistema interno · Propiedad Horizontal

Una copropiedad con su operación en una base de datos, no en hojas sueltas

De reservas pedidas por WhatsApp, cuadernos de portería y censos en Excel a Comunidad 360: un portal por copropiedad con censo, reservas de zonas comunes, PQRD, documentos y noticias, en producción para Edificio Monte Río PH y otras dos copropiedades.

Cliente
Comunidad 360 · Edificio Monte Río PH, Urbanity 2 PH y una tercera copropiedad
Mi rol
Producto, arquitectura de datos, backend Supabase y despliegue por instancia
Periodo
2026 · en producción
Usuario
Administración, portería y copropietarios (titulares)
Equipo
ialabs + administración de cada copropiedad
Stack
React + Vite · Supabase (PostgreSQL + RLS + Edge Functions) · Resend · Docker + Dokploy
76 pantallas
Censo, reservas, PQRD, documentos, noticias, clasificados y guías
fuente: src/pages del repositorio
+40 tablas
Modelo relacional de la copropiedad, con políticas de seguridad por fila
fuente: migraciones Supabase
3 conjuntos
Copropiedades en producción, cada una con su propio proyecto Supabase
fuente: instancias del repositorio
4 roles
Super admin, administración, portería y titular, con rutas protegidas
fuente: enum app_role
EXP-05 ficha de experimento · v0.1
en producción
01 · hipótesis Si la operación diaria de cada copropiedad (censo, reservas, solicitudes y comunicados) vive en un solo portal con sus reglas en la base de datos, la administración deja de depender de chats, cuadernos y hojas de cálculo.
02 · método Portal en React sobre un proyecto Supabase por copropiedad, con reglas de reserva en PostgreSQL, correos transaccionales con Resend y despliegue por instancia con Docker y Dokploy.
03 · resultado En producción para Edificio Monte Río PH y otras dos copropiedades, con el censo de Monte Río cargado en la plataforma.
04 · siguiente iteración Portal financiero, control de visitantes y app instalable (PWA) para residentes.
en producción · responsable Mateo Piza · evidencia: repositorio Comunidad 360 (privado)
01 — El problema

La operación de una copropiedad repartida entre WhatsApp, cuadernos y Excel

La administración de una propiedad horizontal vive dispersa: reservas de zonas comunes pedidas por chat, solicitudes que nadie numera, un cuaderno en portería y un censo de residentes que no coincide con la realidad.

La Ley 675 exige trazabilidad y la administración responde ante el consejo, pero sin un registro común nadie puede demostrar quién pidió qué, cuándo y qué se le respondió.

02 — El insight
"Una copropiedad no necesita otra aplicación genérica: necesita que sus propias reglas —horarios, festivos, depósitos, turnos por unidad— vivan en la base de datos. Si la regla la aplica PostgreSQL y no una persona, dos residentes no pueden reservar el mismo salón a la misma hora."
03 — Antes / después
Antes
  1. Reservas de zonas comunes pedidas por WhatsApp y anotadas a mano.
  2. Solicitudes y quejas sin número ni seguimiento.
  3. Censo de residentes, vehículos y mascotas en hojas de cálculo.
  4. Comunicados y documentos repartidos en chats.
Después
  1. Reservas con calendario, turnos, festivos y aprobación automática o manual.
  2. PQRD con código de consulta para el residente y gestión desde administración.
  3. Censo en línea por pasos: residentes, vehículos, mascotas y personas autorizadas.
  4. Documentos, noticias y guías publicados en el portal de cada copropiedad.
04 — El sistema

Flujo de capacidades automatizadas

entrada
Solicitud del residente
Reserva, PQRD o paso del censo desde el portal de la copropiedad.
contexto
Reglas de la copropiedad
Recursos, horarios, depósitos, festivos colombianos, turnos por unidad y exclusiones entre espacios.
decisión
Validación en PostgreSQL
Un bloqueo por recurso y fecha impide reservas dobles, también en espacios que forman un combo.
acción
Aprobación y aviso
La reserva se aprueba sola o queda para administración, y el residente recibe el correo una sola vez.
control
Panel de administración
Portería y administración ven reservas, depósitos, PQRD y el registro de correos enviados.
DIAGRAMA DE ARQUITECTURA DE FLUJO ialabs / EXP-05
01 · Portal
Residente o titular
→
02 · Reglas
Festivos, turnos, combos
→
03 · PostgreSQL
Bloqueo por recurso
→
04 · Aprobación
Automática o manual
→
05 · Correo
Resend, sin duplicados
05 — Decisiones · capa técnica

Cada pieza, con su razón

Arquitectura basada en trade-offs deliberados y consecuencias reales de negocio.
Tecnología Supabase (PostgreSQL + Edge Functions)
Función Backend por copropiedad
Decisión y trade-off Un proyecto Supabase por cliente en lugar de una columna de inquilino: los datos de una copropiedad nunca comparten base con otra. Trade-off: es el mayor costo de operación y cada instancia se despliega aparte.
Consecuencia Aislamiento total entre copropiedades
Tecnología Reglas en PostgreSQL
Función Reservas sin conflictos
Decisión y trade-off Bloqueo transaccional por recurso y fecha, festivos colombianos 2026–2028, márgenes entre turnos y exclusión mutua entre espacios. Trade-off: cambiar una regla es una migración, no un ajuste en pantalla.
Consecuencia Dos residentes no pueden reservar el mismo espacio a la vez
Tecnología Resend + Edge Functions
Función Correos transaccionales
Decisión y trade-off Cada envío lleva una clave de entrega única, así un reintento no duplica el correo; las invitaciones validan la sesión dentro de la función. Trade-off: las funciones se despliegan instancia por instancia.
Consecuencia Avisos confiables, sin correos repetidos
Tecnología Docker + Dokploy
Función Despliegue por instancia
Decisión y trade-off Cada copropiedad tiene su carpeta de instancia, su dominio y su modo demo o producción, con despliegue desde GitHub Actions. Trade-off: el CI todavía no corre pruebas.
Consecuencia Una copropiedad nueva sale de la misma base de código
06 — Evidencia
TELEMETRÍA DE PROYECTO en producción
Una copropiedad con su operación en una base de datos, no en hojas sueltas
De reservas pedidas por WhatsApp, cuadernos de portería y censos en Excel a Comunidad 360: un portal por copropiedad con censo, reservas de zonas comunes, PQRD, documentos y noticias, en producción para Edificio Monte Río PH y otras dos copropiedades.
PortalReglasPostgreSQLAprobaciónCorreo
De la solicitud del residente a la reserva confirmada. Abajo, cómo se valida una reserva dentro de la base de datos.
$ rpc reservar(recurso, fecha, turno)
[lock] pg_advisory_xact_lock(recurso + fecha)
[rules] festivo: no · turnos de la unidad en el día: dentro del límite
[combo] espacios vinculados libres en esa franja: OK
[approve] aprobación automática programada
[notify] correo al residente · clave de entrega única: OK
07 — Quién hizo qué
ialabs
Producto, arquitectura de datos, backend Supabase, portal en React, reglas de reserva, correos y despliegue por instancia; carga del censo de Monte Río.
Equipo del cliente
Administración de cada copropiedad: censo, reglas de uso de zonas comunes y validación en operación.
Terceros
Supabase, Resend y Dokploy.
08 — Qué es distinto

Lo habitual son aplicaciones genéricas de administración donde las reglas las aplica una persona. Aquí las reglas de cada copropiedad viven en la base de datos, y cada cliente tiene su propia base: sus datos no comparten infraestructura con otra copropiedad.

09 — Lecciones y siguiente iteración
  • Cuando una regla protege un recurso compartido, tiene que vivir en la base de datos: un bloqueo transaccional evita lo que ninguna validación en pantalla puede evitar.
  • Límite conocido: un proyecto por copropiedad encarece la operación, y la suite de pruebas automatizadas todavía es mínima.
  • Siguiente paso: portal financiero, control de visitantes y app instalable para residentes.
From Idea to Infinity.

¿Tu copropiedad todavía se administra por WhatsApp?

En 48 horas te devolvemos un diagnóstico con el resultado que podemos prometer.