Caso de estudio
Plan Tracker
Aplicación colaborativa full stack para planificar y programar actividades en grupo.
Rol
Desarrollo completo
Año
2026
Stack
Next.js · Prisma · PostgreSQL
Resumen
Plan Tracker es una aplicación colaborativa de planificación en grupo. Cualquier miembro puede proponer planes a través de una bandeja compartida; el admin los organiza por prioridad en tres niveles: N1 para planes del día a día, N2 para escapadas de fin de semana y N3 para ocasiones especiales. El sistema lleva el control de cuánto tiempo ha pasado desde el último plan ejecutado en cada nivel y envía notificaciones por email cuando se acerca la fecha.
Decidí construirlo desde cero con un stack moderno para tener control total sobre la lógica de negocio y consolidar el ciclo completo de desarrollo full stack: diseño de base de datos, autenticación, API REST, notificaciones transaccionales, UI reactiva y despliegue en producción.
El reto
El reto no era solo guardar una lista de planes. Era garantizar que los tres niveles de prioridad se respetaran a lo largo del tiempo sin que nadie tuviera que recordarlo: que las ocasiones especiales (N3) no se posterguen indefinidamente, que las escapadas (N2) tengan su hueco y que los planes del día a día (N1) no acaparen toda la atención.
Encima, la aplicación tenía que ser multiusuario con roles diferenciados (admin y miembro), permitir que cualquiera proponga planes, enviar notificaciones por email de forma automática cuando se acerca la fecha y exponer una página de demo pública sin necesidad de registro.
Arquitectura y decisiones
La aplicación se estructura en tres capas bien diferenciadas:
- API REST con rutas de Next.js App Router separadas para planes, sugerencias y tracking. Cada ruta valida la sesión y el rol antes de devolver o modificar datos.
- Modelo de datos en PostgreSQL con Prisma ORM: usuarios con roles (ADMIN/MEMBER), planes con categorías personalizables y un modelo de Tracking independiente por nivel que registra la última ejecución y calcula el próximo vencimiento.
- Autenticación con NextAuth 4 y sesiones persistentes. La redirección al login, al dashboard o al formulario de nuevo plan se resuelve en el servidor según el rol.
- Notificaciones transaccionales con Resend: emails automáticos cuando se acerca la fecha del siguiente plan en cada nivel.
- UI dividida en componentes de responsabilidad única: PlanForm, PlanInbox con filtros y ordenación múltiple, LevelCounters con contadores de días por nivel y página de demo pública sin registro.
Dificultades y aprendizajes
Estos fueron los puntos donde más tuve que pensar:
Lógica de scheduling por niveles
El modelo de Tracking no es un simple contador: almacena cuándo se ejecutó por última vez un plan de cada nivel y calcula los días restantes en función de un intervalo. Conseguir que esta lógica fuera coherente entre la base de datos y la UI, sin lecturas inconsistentes ni actualizaciones fantasma, fue el nudo técnico central del proyecto.
Autenticación con roles sin librerías de autorización
NextAuth gestiona la sesión pero la lógica de permisos (quién puede crear, editar o eliminar) la implementé explícitamente en cada ruta API. Garantizar que un miembro no ejecutara operaciones de admin, y que los errores fueran claros sin filtrar información, fue más delicado de lo que parece.
Estado local coherente con la base de datos
La bandeja de entrada tiene filtros, orden y asignación de niveles que modifican la lista localmente sin recargar la página. Mantener sincronía entre el estado React y lo que hay en base de datos, especialmente tras mutaciones concurrentes, me obligó a diseñar las actualizaciones con cuidado.
Iré ampliando esta sección según el proyecto evolucione.
Resultado
Plan Tracker está en producción y en uso real. El resultado más valioso no fue el código sino comprobar que un modelo de datos bien diseñado puede resolver un problema de coordinación que antes dependía de la memoria o la improvisación. Este proyecto me consolidó en el desarrollo full stack y me reafirmó en algo que ya sabía del backend de empresa: los sistemas que importan de verdad son los que siguen funcionando cuando los datos son imperfectos y los usuarios no hacen lo que esperas.