GRI Admin
El mantenimiento de residenciales: de hojas sueltas a un sistema con evidencia.
Desarrollé GRI Admin, la app web con la que se administra un residencial día a día: el programa mensual de mantenimiento, limpieza y jardinería, los trabajos urgentes, los materiales que se piden y la evidencia fotográfica de todo lo realizado. Entregué el sistema completo —modelo de datos, API, interfaz y despliegue— en dos meses.
- Mi rol
- Arquitectura, backend, frontend y despliegue
- Sector
- Inmobiliario / Residencial
- Alcance
- App web
- 2 meses
- De cero a sistema en producción
- 3
- Departamentos con vista propia
- 4
- Ejes de filtrado en cada bloque
- 3 formatos
- Exportación: PDF, Word y Excel
Stack
- React (Vite)
- Tailwind CSS
- Node.js
- Express
- TypeScript
- MongoDB
- Docker
- Dokploy (CD/CI)
Pantallas
Capturas del sistema real en operación.
App web
Programa mensual de mantenimiento
El concentrado de todas las actividades programadas del mes, con su avance, y la vista de cada departamento — mantenimiento, limpieza y jardinería — donde el personal ve sólo sus tareas asignadas, filtrables por condominio, área, responsable y estado.
App web
Urgencias, recursos y reportes
Los trabajos urgentes fuera del plan, con fecha límite y semáforo que marca lo vencido y lo que está por vencer. La gestión de materiales y herramientas que pide cada programa, con su estado y su evidencia. Y el generador de reportes, que exporta a PDF o Word con las fotos de cada actividad, o a Excel.
El problema
Administrar residenciales es coordinar tres frentes a la vez: el programa mensual de mantenimiento, la limpieza y la jardinería, más lo urgente que se atraviesa y los materiales que hay que gestionar para atenderlo. Todo eso se llevaba en hojas sueltas. Con ese método no hay un concentrado del avance del mes, la evidencia de lo hecho queda dispersa entre fotos y papeles, y el reporte de cierre se arma a mano cada vez.
Lo que construí
Modelé la operación alrededor de una sola pieza: la actividad programada, ligada a su condominio, su área, su responsable y su estado. Sobre esa base construí el tablero que calcula el avance del mes, las vistas por departamento donde el personal ve únicamente sus tareas asignadas, el bloque de urgentes con semáforo por fecha límite y la gestión de recursos —materiales y herramientas— con su ciclo de pendiente, gestionado o rechazado y su evidencia fotográfica. El cierre lo resolví con un generador de reportes que aplica los filtros que se necesiten y exporta a PDF o Word con las fotos incrustadas, o a Excel cuando lo que se ocupa son los datos. Lo desplegué en contenedores con CI/CD.
Decisiones técnicas
- 01
El programa mensual como eje del modelo
Modelé todo alrededor de la actividad programada: cada una cuelga de un condominio, un área y un responsable, con su estado. El avance del mes no se captura, se calcula sobre esas actividades, y por eso el tablero no se desincroniza de la operación real.
- 02
Cada departamento entra sólo a lo suyo
Mantenimiento, limpieza y jardinería comparten la misma estructura de datos pero no la misma vista. Resolví el acceso por rol para que cada uno vea sus tres bloques —programa del mes, extras y urgentes— filtrables por condominio, área, responsable y estado, sin ruido de los demás.
- 03
Semáforo derivado de la fecha límite
Las urgencias viven fuera del plan y sólo importan por su vencimiento. Derivé el estado visual de la fecha límite en vez de pedirle a alguien que marque el retraso a mano: lo vencido y lo que está por vencer salta sin tener que buscarlo.
- 04
El reporte con la evidencia adentro
El cierre de mes se armaba a mano sobre las hojas sueltas. Construí un generador que aplica los filtros que se quieran y exporta a PDF o Word con las fotos de cada actividad incrustadas, o a Excel cuando lo que se necesita es el dato suelto.
- 05
TypeScript de extremo a extremo sobre MongoDB
Los tres departamentos comparten estructura, pero cada actividad arrastra recursos y evidencia distintos. Elegí MongoDB para modelar esa variación sin pelearme con el esquema en cada ajuste, y puse TypeScript encima para que la flexibilidad no se volviera un contrato ambiguo entre API y frontend. Todo empaquetado en Docker con CI/CD en Dokploy.
Siguiente proyecto
Gigante de los Azulejos
Ecommerce de azulejos y mármoles conectado al sistema que la empresa ya usaba.