Case study · project-manager
Project Manager
Plataforma full stack para gestión de proyectos, tareas, presupuestos y colaboración.
Contexto
El proyecto
Project Manager fue desarrollado como una plataforma de gestión para centralizar proyectos, tareas, usuarios, presupuestos y comunicación dentro de una misma aplicación.
Punto de partida
El problema
- Información distribuida entre herramientas y conversaciones.
- Seguimiento manual de tareas y responsables.
- Dificultad para entender el avance real de cada proyecto.
- Poca visibilidad conjunta de tareas y presupuestos.
- Necesidad de centralizar operaciones y comunicación.
Enfoque
La solución
Se desarrolló una arquitectura full stack con responsabilidades explícitas en cada capa.
Frontend
React + Vite
Backend
Django + Django REST Framework
Autenticación
JWT
Base de datos
PostgreSQL
Realtime
Django Channels + Redis
Infraestructura
Docker
La demo pública integrada en el portfolio funciona con datos sintéticos y estado local efímero para no exponer infraestructura ni datos reales.
Impacto
Resultados
Producto
Funcionalidades
Dashboard
Resumen operativo de proyectos, tareas y actividad.
Gestión de proyectos
Espacios de trabajo con responsables, equipos y seguimiento.
Gestión de tareas
Estados, prioridades, responsables y fechas de entrega.
Presupuestos
Modalidades globales y desglose de costos por tarea.
Usuarios y roles
Acciones y vistas adaptadas a permisos definidos.
Calendario
Lectura temporal de entregas y vencimientos.
Analítica
Distribución de trabajo por estado y tipo.
Chat
Conversación contextual vinculada a proyectos y tareas.
Responsive
Flujos adaptados para escritorio, tablet y móvil.
Sistemas
Arquitectura
Aplicación
Frontend
↓ conecta con
API REST
↓ conecta con
Django
↓ conecta con
PostgreSQL
Tiempo real
Realtime
↓ conecta con
Channels
↓ conecta con
Redis
Ingeniería
Decisiones técnicas
DECISION_01
Separación frontend/backend
La interfaz y la API evolucionan con responsabilidades separadas.
DECISION_02
Autenticación JWT
El backend protege recursos y representa identidad en cada solicitud.
DECISION_03
WebSocket para colaboración
Los eventos llegan sin consultas periódicas.
DECISION_04
Permisos por proyecto
El acceso se evalúa por espacio de trabajo.
DECISION_05
Docker reproducible
Los servicios comparten configuración entre entornos.
DECISION_06
Demo pública aislada
Datos sintéticos y memoria local sin infraestructura privada.
Complejidad
Retos técnicos
Control de acceso en WebSockets
Validar identidad y alcance también en conexiones persistentes.
Aislamiento de sesiones
Evitar que eventos o recursos crucen contextos de trabajo.
Sincronización de estado
Coordinar mutaciones REST, eventos realtime y estado de interfaz.
Gestión de permisos
Resolver acciones por rol sin delegar seguridad al frontend.
Demo sin persistencia
Conservar la experiencia sin exponer datos ni servicios reales.
Explora la demo
La demo utiliza datos ficticios y los cambios se eliminan al recargar.
Entrar a la demo