Firenow Solutions Platform
De información repartida entre hojas de cálculo, tickets y correos, a una sola plataforma donde la operación se ve completa.
El problema
Firenow es una empresa de servicios de TI, y su información vivía en pedazos: los datos de clientes en un lado, los servicios contratados en otro, los tickets en GLPI y las licencias con sus vencimientos en hojas de cálculo. Responder algo tan simple como «a este cliente qué le vendimos y qué le vence este mes» era un trabajo manual de varias personas.
Lo que construí
Diseñé y construí una plataforma modular tipo ERP/CRM con mesa de servicio: clientes, sucursales, usuarios internos y de cliente, servicios, productos, licencias, entidades fiscales, contenido público y auditoría. El backend sigue Clean Architecture en cuatro capas, de modo que la lógica de negocio no conoce el framework ni la base de datos y se puede probar sola.
Qué cambió
Hoy está en producción, con alrededor de veinte módulos de dominio y treinta funcionalidades en frontend. Agregar un módulo nuevo no obliga a tocar los existentes, y cada cambio pasa por integración continua con linter, verificación de tipos y pruebas antes de poder integrarse.
La aplicación
Cómo se ve en producción
Decisiones técnicas
Por qué está construido así
- Clean Architecture real: dominio, aplicación, infraestructura e interfaces en capas separadas, con repositorios como interfaces e implementaciones inyectadas.
- Autenticación con tokens de acceso y de refresco firmados con secretos distintos, para que comprometer uno no comprometa el otro.
- Sistema de permisos donde el catálogo vive en el código y el panel solo asigna: un permiso que el backend no sabe verificar no debería poder existir.
- Auditoría por middleware para trazabilidad de acciones sobre datos de clientes.
- Limitador de peticiones propio con Redis (contador con expiración por IP y ámbito) que responde 429 indicando cuándo reintentar.
- Integración con GLPI mediante un cliente HTTP con token cacheado y control de expiración, escondido detrás de un puerto para poder sustituir la herramienta sin tocar el resto.
- Frontend en Next.js con App Router, rutas separadas por área y código organizado por funcionalidad; estado de servidor y estado de cliente deliberadamente separados.
- Despliegue con Docker Compose (con healthchecks y arranque ordenado), Nginx como proxy inverso y CI en GitHub Actions.