Un edificio de 80 departamentos en Santiago, mezcla de departamentos residenciales y locales comerciales en el primer piso. Administración externa con 3 personas, llevando todo en una planilla Excel que se había vuelto crítica para el negocio.

El cierre mensual les tomaba 3 días completos de trabajo manual y generaba errores costosos. Lo automatizamos en 6 semanas. Acá está exactamente qué hicimos y cuánto cambió.

Sin nombre del edificio, sin nombre de la administración. Es un caso real con los detalles que se pueden compartir.

El problema concreto

Cada mes, el día 5, el equipo administrativo tenía que:

1. Calcular los gastos comunes del mes anterior. Eso incluye:
   • Luz, agua, gas y mantención del edificio.
   • Sueldos de conserjes y aseo.
   • Reparaciones puntuales con boletas.
   • Aporte al fondo de reserva (% definido por reglamento).
2. Prorratear cada gasto por departamento. Pero no es proporcional a la cantidad de departamentos: es proporcional a los metros cuadrados de cada uno. Locales comerciales tenían un coeficiente distinto al residencial.
3. Sumar consumos individuales de agua caliente y gas (cada departamento tiene medidor propio).
4. Calcular el detalle por departamento: monto base prorrateado + consumos individuales + saldo anterior si había morosidad + intereses por mora si correspondía.
5. Generar 80 boletas en PDF con el detalle de cada uno.
6. Mandarlas por correo y subirlas al portal del edificio.
7. Actualizar la planilla maestra con los nuevos saldos para el mes siguiente.

Todo eso, con un Excel de 12 hojas linkeadas con fórmulas de tabla dinámica que se rompían cada vez que alguien agregaba una fila.

Lo que costaba

• 3 días enteros de la administradora cada mes (16 a 24 horas).
• 2–3 errores típicos por cierre, descubiertos por los propios residentes que pagaban menos o más de lo que correspondía.
• Discusiones recurrentes con residentes que no entendían el detalle.
• Pago de morosidad fragmentado: a veces se cobraba interés, a veces se olvidaba.

Y lo más caro de todo: la administradora era la única persona que sabía correr todo el proceso. Si se enfermaba o se iba, el cierre no salía.

Lo que construimos

Una aplicación web en Go con base de datos Postgres y frontend HTMX + Templ. Multi-tenant desde el día uno (la administración tiene 4 edificios más en cartera, queremos que el sistema escale).

Modelo de datos (simplificado):

• edificios (id, nombre, configuración de coeficientes)
• unidades (id, edificio_id, número, M², tipo, propietario actual)
• gastos (id, edificio_id, mes, concepto, monto, prorrateable)
• lecturas_individuales (id, unidad_id, mes, agua_caliente, gas)
• pagos (id, unidad_id, fecha, monto, mes_aplicado)
• cierres_mensuales (id, edificio_id, mes, estado, generado_en)
• boletas (id, cierre_id, unidad_id, detalle_json, pdf_path)

Row-level security en Postgres para que la administración solo vea los edificios que administra.

Flujo del cierre mensual:

1. Administradora carga gastos del mes (5–10 conceptos típicos).
2. Carga lecturas individuales (las recibe del conserje en una planilla).
3. Click en “Generar cierre”.
4. El sistema:
   • Calcula prorrateo por M² aplicando el coeficiente residencial / comercial.
   • Suma consumos individuales por unidad.
   • Aplica saldos anteriores y morosidad (con regla de interés definida por edificio).
   • Genera 80 PDFs con el detalle (usando chromedp con plantilla HTML, ya escribimos sobre eso en otra nota).
   • Manda 80 correos con el PDF adjunto vía SMTP.
   • Actualiza saldos en la base.
5. Si algo falla, queda registrado y la administradora puede re-disparar pasos individuales sin volver a empezar.

Tiempo total que tarda el sistema: 4 minutos.

Lo que costaba después

• 20 minutos de la administradora cargando gastos y lecturas.
• 4 minutos corriendo el cierre.
• 0 errores de cálculo desde que está en producción (8 cierres ya ejecutados al momento de escribir esto).
• 0 dependencia de una persona específica: cualquiera del equipo de 3 puede correr el proceso siguiendo el wizard.

Las discusiones con residentes bajaron porque ahora la boleta tiene un detalle claro de qué se cobró y por qué.

Lo que costó construirlo

• 6 semanas calendario de un developer senior, con la administradora respondiendo dudas 2 veces por semana.
• Stack: Go + Postgres + Templ + HTMX + Cloud Run + Cloud SQL.
• Costo de infra mensual hoy: ~USD 18 al mes (multi-tenant, va a bajar por edificio cuando agreguen los otros 4).

Lo que no es mágico

Vale ser honesto sobre qué partes costaron tiempo:

• Acordar las reglas exactas de morosidad con la administración. Cada edificio tiene reglamento propio. Esto tomó 5 días repartidos en 3 semanas.
• Limpiar la planilla histórica para migrar a la base. Departamentos con saldos negativos sin explicación, fechas en 4 formatos distintos, unidades subdivididas que no estaban marcadas. 2 días enteros.
• Onboarding de las 3 personas del equipo administrativo. La primera vez, todas miraban con desconfianza. Después del primer cierre exitoso fue distinto.

Lo que no costó tiempo fue lo que la gente se imagina: la generación de PDFs, el cálculo del prorrateo, la base de datos. Eso se escribe rápido cuando el modelo está claro. El modelo claro es el trabajo difícil, y se hace conversando con el cliente, no en el editor de código.

La parte que se exporta a otros

Esto que armamos para un edificio funciona para cualquier administración de comunidades en Chile y LatAm:

• Edificios residenciales / mixtos.
• Condominios horizontales (casas con áreas comunes).
• Centros comerciales con prorrateo por local.
• Apart-hoteles con régimen de comunidad.

Cambian los coeficientes, los conceptos de gasto y las reglas de morosidad. La estructura del proceso es la misma.

¿Tu administración o comunidad tiene un cierre mensual que se hace en Excel y duele? Cuéntanos por WhatsApp o correo. Primera conversación, 30 minutos, gratis.

← Volver a notas