en producción
Caso — Plataforma · Propiedad Horizontal

Una asamblea de propiedad horizontal que se acredita, se vota y se sella en línea

De listas en papel, poderes sin verificar y conteos a mano a Asamblea 360: acreditación por QR o selfie, poderes confirmados por código, voto ponderado por coeficiente con integridad en la base de datos y el resultado de cada punto sellado.

Cliente
Asamblea 360 · copropiedades Urbanity 2, Rivera de Suramérica y Campura
Mi rol
Producto, arquitectura, backend Supabase, Edge Functions y aprovisionamiento por cliente
Periodo
2026 · en producción
Usuario
Administración, moderadores y copropietarios, presenciales o virtuales
Equipo
ialabs + administración de cada copropiedad
Stack
React + Vite · Supabase (PostgreSQL + RLS + Realtime) · Edge Functions (Deno) · Twilio WhatsApp · Resend
28 tablas
Todas con seguridad por fila (RLS)
fuente: supabase/functions
24 funciones
Edge Functions en Deno: acceso, acreditación, poderes, voto y WhatsApp
fuente: supabase/functions
6 reglas
Mayorías de la Ley 675 (arts. 45 y 46) evaluadas por punto
fuente: dominio compartido
4 capas
Pruebas unitarias, de base de datos (pgTAP), de funciones y de extremo a extremo en CI
fuente: pipeline de CI
EXP-07 ficha de experimento · v0.1
en producción
01 · hipótesis Si el peso de cada voto lo fija la base de datos y no el cliente, y cada resultado queda sellado al cerrar el punto, la asamblea puede ser presencial, virtual o híbrida sin abrir la puerta a una impugnación por el conteo.
02 · método Supabase con integridad en triggers, 24 Edge Functions con un dominio de cálculo compartido entre navegador y servidor, resultados en tiempo real y una instancia aprovisionada por cliente.
03 · resultado En producción por instancia de cliente, con acreditación presencial y virtual, voto por WhatsApp y reporte de auditoría en PDF al finalizar.
04 · siguiente iteración Sellar también cada voto individual e integrar el agente VERA para acreditar por WhatsApp.
en producción · responsable Mateo Piza · evidencia: repositorio Asamblea 360 + núcleo abierto Asamblea360-OpenSource
01 — El problema

Asambleas que se impugnan por un coeficiente mal sumado

En propiedad horizontal la asamblea decide sobre dinero común y cada voto pesa según el coeficiente de la unidad. Acreditar asistentes, verificar poderes y contar votos a mano consume la reunión entera, y muchos copropietarios no participan porque exige estar presentes, con papeles, a una hora fija.

Cualquier descuadre en los coeficientes o en el registro del quórum abre la puerta a una impugnación ante jueces civiles. Y si el sistema deja que el navegador del participante diga cuánto pesa su voto, el riesgo ya no es contar mal: es que alguien cuente por ti.

02 — El insight
"El conteo no puede depender de quien vota. Si la base de datos toma el coeficiente de la acreditación, si solo vota quien acreditó la unidad y si el resultado de cada punto se sella con un hash al cerrarse, la confianza deja de ser una promesa del software y pasa a ser una propiedad del esquema."
03 — Antes / después
Antes
  1. Acreditación con listas en papel y verificación visual de identidad.
  2. Poderes en hojas sueltas, sin forma de validarlos a tiempo.
  3. Conteo de votos a mano, con riesgo de errores de coeficiente.
  4. Acta redactada desde cero durante días o semanas.
Después
  1. Acreditación presencial con QR de un solo uso, o virtual con selfie.
  2. Una sola delegación por unidad, confirmada por código OTP.
  3. Un voto por unidad y por punto, con el peso fijado por la base de datos.
  4. Resultado de cada punto sellado con sha256 y reporte de auditoría en PDF.
04 — El sistema

Flujo de capacidades automatizadas

entrada
Ingreso sin contraseña
Torre y apartamento, nombre y código de 6 dígitos por correo; el staff también puede acreditar.
contexto
Acreditación y poderes
La acreditación fija el coeficiente de la unidad y queda inmutable; los poderes se confirman por OTP.
decisión
Punto activo y mayoría
Solo se vota en el único punto activo, con una de 6 reglas de mayoría de la Ley 675.
acción
Voto con integridad
Un trigger toma el peso de la acreditación y rechaza a quien no acreditó la unidad; el voto también entra por WhatsApp.
control
Cierre y sello
Al cerrar el punto se guardan el quórum y un sha256 del resultado, sin posibilidad de editarlo; al final, reporte en PDF.
DIAGRAMA DE ARQUITECTURA DE FLUJO ialabs / EXP-07
01 · Acceso
OTP por correo
→
02 · Acreditación
QR, selfie o staff
→
03 · Voto
Web o WhatsApp
→
04 · Triggers
Peso por coeficiente
→
05 · Sello
sha256 por punto
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 y tiempo real
Decisión y trade-off RLS en las 28 tablas, 24 Edge Functions en Deno y suscripciones en tiempo real para quórum y resultados. Trade-off: el límite de conexiones en tiempo real del plan.
Consecuencia Resultados en pantalla sin recargar
Tecnología Integridad en triggers
Función El peso del voto, fuera del cliente
Decisión y trade-off Se movió a la base de datos tras detectar que un participante podía alterar el peso de su voto: el trigger toma el coeficiente de la acreditación. Trade-off: la lógica crítica vive en SQL.
Consecuencia Nadie decide cuánto pesa su propio voto
Tecnología Dominio compartido
Función Mayorías de la Ley 675
Decisión y trade-off Las 6 reglas de mayoría y los cálculos de quórum son el mismo código en el navegador y en las Edge Functions. Trade-off: un módulo que debe funcionar en los dos entornos.
Consecuencia La pantalla y el servidor nunca calculan distinto
Tecnología Instancia por cliente
Función Aprovisionamiento y evidencia
Decisión y trade-off Un comando crea el proyecto Supabase y el sitio de cada cliente; la evidencia de cada asamblea se archiva cifrada, con retención de 5 años. Trade-off: más proyectos que operar.
Consecuencia Datos y evidencia de cada copropiedad aislados
06 — Evidencia
TELEMETRÍA DE PROYECTO en producción
Una asamblea de propiedad horizontal que se acredita, se vota y se sella en línea
De listas en papel, poderes sin verificar y conteos a mano a Asamblea 360: acreditación por QR o selfie, poderes confirmados por código, voto ponderado por coeficiente con integridad en la base de datos y el resultado de cada punto sellado.
AccesoAcreditaciónVotoTriggersSello
Del ingreso del copropietario al resultado sellado de cada punto. Abajo, lo que ocurre en la base de datos cuando llega un voto.
$ POST /functions/v1/register-vote
[auth] sesión del participante · punto activo único: OK
[trigger] votos_integridad: la unidad la acreditó quien vota
[trigger] peso = coeficiente de la acreditación, no el enviado por el cliente
[unique] un voto por unidad y punto: OK
[close] quórum + sha256 del resultado · UPDATE/DELETE bloqueados: OK
07 — Quién hizo qué
ialabs
Producto, arquitectura y build: esquema con integridad en triggers, 24 Edge Functions, paneles de administración y moderación, voto por WhatsApp, aprovisionamiento por cliente y archivo cifrado de evidencia.
Equipo del cliente
Administraciones de copropiedades: aportación de censos, validación jurídica y firma de actas.
Terceros
Supabase, Twilio (WhatsApp), Resend y Cloudflare Pages.
08 — Qué es distinto

Lo habitual son plataformas de votación que piden confiar en cómo cuentan. Aquí el peso de cada voto y el sello de cada resultado los impone el esquema de la base de datos, y la primera versión del agente de acreditación por WhatsApp se publicó como código abierto (MIT).

09 — Lecciones y siguiente iteración
  • La integridad de un voto no se valida en la pantalla: se impone en la base de datos, donde el participante no puede tocarla.
  • Límite conocido: el sello es por punto, no por voto individual, y los planes gratuitos de correo y base de datos limitan las asambleas grandes.
  • Siguiente paso: sello por voto individual e integración del agente VERA para acreditar por WhatsApp.
From Idea to Infinity.

¿Tus asambleas todavía se cuentan a mano?

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