GRI Admin
Residential upkeep run off loose paper — now a system that proves what got done.
I built GRI Admin, the web app a residential complex is run on day to day: the monthly maintenance, cleaning and gardening program, urgent jobs outside the plan, material requests, and photo evidence of everything completed. I shipped the whole system — data model, API, interface and deployment — in two months.
- My role
- Architecture, backend, frontend and deployment
- Sector
- Inmobiliario / Residencial
- Scope
- App web
- 2 months
- From zero to production
- 3
- Departments, each with a view
- 4
- Filter axes on every block
- 3 formats
- Export: PDF, Word and Excel
Stack
- React (Vite)
- Tailwind CSS
- Node.js
- Express
- TypeScript
- MongoDB
- Docker
- Dokploy (CD/CI)
Screens
Screenshots from the live system.
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.
The problem
Running residential complexes means coordinating three fronts at once: the month's maintenance program, cleaning and gardening, plus whatever urgent work cuts in and the materials needed to handle it. All of it lived on loose sheets of paper. That leaves no single view of monthly progress, scatters the proof of what was actually done across photos and paperwork, and means the closing report gets rebuilt by hand every month.
What I built
I built the model around one primitive: the scheduled activity, tied to its complex, its area, its assignee and its status. On top of that came the dashboard that computes monthly progress, per-department views where staff see only their own assignments, an urgent-work block with a due-date traffic light, and resource handling for materials and tools with a pending / sourced / rejected lifecycle and photo evidence attached. Month-end closes through a report generator that takes any combination of filters and exports to PDF or Word with each activity's photos embedded, or to Excel when raw data is what's wanted. I shipped it containerized with CI/CD.
Technical decisions
- 01
The monthly program as the core of the model
Everything hangs off the scheduled activity: each one belongs to a complex, an area and an assignee, and carries its own status. Monthly progress isn't typed in, it's derived from those records — so the dashboard can't drift from what's actually happening on site.
- 02
Each department sees only its own work
Maintenance, cleaning and gardening share one data structure but not one view. I scoped access by role so each crew gets its three blocks — the month's program, extra jobs, and urgent tasks — filterable by complex, area, assignee and status, with none of the other departments' noise.
- 03
Traffic light derived from the due date
Urgent work sits outside the plan and only matters by its deadline. I derived the visual state from the due date instead of asking someone to flag delays by hand, so overdue and about-to-be-overdue surface on their own rather than waiting to be found.
- 04
Reports that carry the evidence inside
The month-end close used to be assembled by hand off the loose sheets. I built a generator that applies any combination of filters and exports to PDF or Word with each activity's photos embedded, or to Excel when the raw data is what's needed.
- 05
TypeScript end to end over MongoDB
The three departments share a structure, but every activity drags along different resources and evidence. I picked MongoDB to model that variation without fighting the schema on each adjustment, and put TypeScript on top so the flexibility never turned into an ambiguous contract between API and frontend. All of it ships in Docker with CI/CD on Dokploy.
Next project
Gigante de los Azulejos
A tile and marble ecommerce wired into the system the company already ran on.