Contexto y objetivo
Agrooe Cashback nació como una iniciativa para impulsar el comercio local mediante una plataforma digital de compra y visibilidad de productos de proximidad.
El objetivo técnico fue construir una base sólida de producto desde cero, cubriendo flujo completo de usuario y negocio:
- Descubrimiento de productos.
- Gestión de cuentas.
- Panel administrativo.
- Soporte para diferentes tipos de perfil (cliente y empresa).
Problema que resolvía
Muchos comercios locales no tienen una infraestructura digital unificada para mostrar catálogo, gestionar presencia y conectar con clientes de forma simple.
La plataforma buscó resolver:
- Fragmentación de canales de venta.
- Falta de panel centralizado para gestión.
- Escasa trazabilidad de usuarios y sesiones.
- Necesidad de una experiencia web moderna y responsive.
Decisiones técnicas
1) Arquitectura full stack con separación clara
Se diseñó frontend y backend como capas diferenciadas para facilitar mantenimiento, iteración y escalado funcional.
2) Autenticación con JWT
JWT permitió controlar sesiones de usuario y proteger operaciones sensibles, manteniendo un flujo de login consistente.
3) Dashboard de control
Se incorporó un panel para administración y gestión de datos clave de la plataforma, evitando dependencia de cambios manuales en base de datos.
4) Diseño orientado a roles
Se contemplaron caminos distintos para:
- Usuario comprador.
- Perfil empresa/publicador de productos.
Implementación (resumen)
- Desarrollo completo desde concepto hasta ejecución técnica.
- Construcción de frontend y backend en paralelo.
- Definición de endpoints y documentación con Swagger.
- Integración de autenticación y control de sesión.
- Implementación de funcionalidades orientadas a comercio local y experiencia de uso.
Funcionalidades destacadas
- Registro e inicio de sesión.
- Acceso con diferentes flujos según tipo de cuenta.
- Publicación/gestión de productos para empresas.
- Flujo de consulta/compra para usuarios.
- Componentes de geolocalización y contexto de proximidad para localizar disponibilidad cercana (según caso de uso del proyecto).
Tradeoffs reales
- El alcance funcional fue amplio para una primera versión, lo que obliga a priorizar backlog y deuda técnica por fases.
- Mantener coherencia entre UX, reglas de negocio y seguridad requiere disciplina de arquitectura desde etapas tempranas.
- En proyectos con contexto real de negocio, la confidencialidad limita la exposición pública de código y detalles internos.
Qué funcionó bien
- Base full stack consistente desde primera iteración.
- Buen encaje entre necesidades de negocio y diseño técnico.
- Stack flexible para evolucionar funcionalidades sin rehacer arquitectura.
Qué ajustaría en siguiente iteración
- Endurecer observabilidad (logs estructurados, trazas y métricas funcionales).
- Añadir más cobertura automatizada (tests e2e de flujos críticos por rol).
- Profundizar en rendimiento de búsqueda/listado y cacheo estratégico.
- Refinar permisos granulares en panel y operaciones sensibles.
Nota sobre código y demo
Por motivos de confidencialidad del proyecto, no se publica repositorio ni demo pública en esta entrada.
Capturas
