De necesidad de negocio a Aplicacion. Construyendo una APP para la Gestión de Servicios Compartidos con IA

Gestionar un edificio de departamentos o un complejo de unidades de alquiler parece una tarea sencilla desde afuera: cobrar el alquiler y pagar los servicios. Sin embargo, quienes están en el frente de batalla saben que la realidad es muy diferente. Calcular consumos proporcionales, lidiar con medidores manuales, rastrear qué inquilino debe qué mes y no perder las fotos de evidencia en grupos de WhatsApp puede convertirse rápidamente en una pesadilla logística y contable.

settings_system_daydream El Reto

En este artículo, quiero compartir la historia de cómo construimos nuestra Aplicación Web de Gestión Centralizada de Consumos y Facturación, un sistema "crash-proof" (a prueba de fallos) diseñado para resolver de raíz el caos administrativo en propiedades compartidas.

1. El Problema: El Caos de las Hojas de Cálculo y las Fotos Perdidas

Antes de concebir la solución, nos enfrentamos a un escenario común pero insostenible. La gestión de los edificios se basaba en procesos manuales y hojas de cálculo desconectadas:

Lecturas en papel o fotos sueltas: El administrador tomaba fotos a los medidores de agua y luz. Estas imágenes se perdían en chats, lo que hacía imposible resolver disputas con inquilinos meses después.
Cálculo manual de tarifas: Las empresas de servicios públicos envían un solo recibo global por edificio. Prorratear el costo exacto por kilovatio (KW) o metro cúbico (m³) para cada departamento (con lecturas que varían mes a mes) era un trabajo manual propenso a errores.
Historial de inquilinos roto: Cuando un inquilino se iba y entraba uno nuevo a mitad de mes, el histórico financiero se corrompía o se perdía.
Arrastre de deudas: Mantener un control del flujo de caja, internet, mantenimiento y arrastrar las deudas del mes pasado al mes actual era tedioso y poco auditable.

Estábamos lidiando con información frágil. Un error de dedo en un Excel podía costar dinero real o dañar la relación con un inquilino. Necesitábamos evolucionar.

2. El Dibujo de la Solución: Un Ecosistema Inmutable y Centralizado

Decidimos tirar el papel y construir una plataforma web centralizada. El objetivo no era solo hacer una calculadora bonita, sino un ecosistema donde el dato fuera inmutable y auditable.

Diseñamos la solución sobre una arquitectura robusta utilizando Node.js, Express y PostgreSQL. La premisa principal fue crear una Interfaz de Página Única (SPA) con un "Contexto de Navegación Global". El administrador selecciona el mes y el edificio una sola vez, y el sistema orquesta todo lo demás:

Motor de Cálculo Global: El sistema recibe el monto total del recibo del edificio y calcula automáticamente el costo unitario por KW y metro cúbico. Este costo se "congela" en la base de datos para ese mes, garantizando que futuras consultas mantengan el valor original.
Historial Dinámico de Contratos: Creamos una estructura que cruza las fechas de consumo con las fechas de alta y baja de los inquilinos. Así, si consultas un reporte de hace dos años, el sistema sabe exactamente quién vivía allí y cuánto pagaba de alquiler base.
Generación de Estados de Cuenta: Con un solo clic, se genera un PDF formal con el balance financiero (deuda anterior, cargos fijos y consumo variable) y la métrica exacta de los medidores.

"Todo bajo una filosofía operativa estricta: El mes se calcula, se audita, se cierra y se vuelve inmutable en la base de datos."

3. Resolución de Desafíos Técnicos: Construyendo a Prueba de Balas

Durante el desarrollo, nos topamos con varios retos técnicos interesantes que resolvimos con ingeniería moderna:

wifi_off

A. Pérdida de Conectividad

Reto: Los medidores están en sótanos sin señal celular o WiFi.

Solución (Offline-First): Captura binaria local guardada en la base de datos del navegador (IndexedDB) con URLs temporales. Sincronización silenciosa en segundo plano al recuperar señal.

build_circle

B. Corrupción por Updates

Reto: Los cambios de esquema en bases de datos rompen sistemas en vivo.

Solución (Autoreparación): Script de Self-Healing al iniciar el contenedor Docker, ejecutando consultas condicionales de tipo ALTER TABLE IF NOT EXISTS antes de aceptar tráfico.

layers

C. Actualización sin Pérdida

Reto: Actualizar el código fuente de la app sin poner en riesgo los archivos de evidencia.

Solución (Desacoplamiento): Arquitectura de contenedores aislados Docker (App + DB) comunicados en red interna. Archivos físicos y datos en volúmenes persistentes del host excluidos de Git.

4. Puesta en Marcha: Despliegue y Continuidad Operacional

El paso final fue llevar esto de un entorno de pruebas a producción. Para asegurar el acceso y la protección de datos, montamos el sistema en un servidor físico Ubuntu utilizando la potencia de Docker Compose.

security

Estrategias de Seguridad y Resiliencia

La seguridad perimetral se delegó en Nginx Proxy Manager con certificados SSL cifrados HTTPS válidos por 10 años, mientras que la persistencia contable se confió a scripts en bash automatizados (backup.sh) encargados de realizar dumps periódicos de PostgreSQL en almacenamiento aislado.

Finalmente, para dormir tranquilos, programamos un script automatizado que realiza volcados periódicos de PostgreSQL. Estos respaldos se alojan en un volumen seguro y protegido, garantizando que el historial contable de los edificios esté blindado contra cualquier desastre contable o del servidor.

Conclusión

Lo que comenzó como un intento por eliminar los errores en hojas de cálculo, evolucionó hasta convertirse en una aplicación virtual, modular y resistente. Este proyecto es una prueba de que, con la arquitectura adecuada y entendiendo el "dolor" del usuario final (operar offline en sótanos, evitar la re-digitación, auditar deudas pasadas), se puede transformar radicalmente la gestión administrativa tradicional en una experiencia tecnológica fluida y segura.