Project Flow
Un workspace interno para dirigir proyectos de agencia sin perder el contexto entre tareas, solicitudes, capacidad del equipo, departamentos, guías y plantillas. Lo construí como una herramienta operativa, no como un tablero decorativo.
vistas operativas
tablas persistidas
routers de API
workspace unificado
Semana real de uso
Un sistema operativo de agencia tiene que servir de lunes a viernes.
Project Flow está pensado para acompañar el ritmo de una agencia: priorizar, coordinar, medir la capacidad, reducir el riesgo y convertir el aprendizaje en procesos reutilizables.
Lunes
Priorizar la semana
Inicio personal, tareas vencidas, bloqueos y planning muestran qué debe moverse primero, antes de que el equipo empiece a ejecutar por inercia.
Martes
Coordinar dependencias
Las solicitudes entre áreas, con responsables y deadlines, hacen visible quién espera a quién y qué tarea queda bloqueada hasta recibir feedback, datos o una aprobación.
Miércoles
Revisar capacidad
La vista semanal cruza horas planificadas, capacidad base, entregas y sobrecarga para ajustar el trabajo antes de que el calendario se rompa.
Jueves
Reducir riesgo
El control global y la actividad ayudan a detectar proyectos con más fricción, tareas críticas y decisiones que no deberían depender de la memoria o del chat.
Viernes
Convertir aprendizaje en sistema
Las guidelines y las plantillas capturan procesos repetibles para que la semana siguiente empiece con menos improvisación y más estructura reutilizable.
El problema
La operativa de agencia se rompe cuando todo vive en sitios distintos.
Proyectos por un lado, tareas por otro, solicitudes en chats, aprobaciones sin dueño claro, procesos en documentos sueltos y la capacidad del equipo calculada a ojo. El resultado es previsible: bloqueos invisibles, prioridades discutidas tarde y contexto perdido.
La necesidad no era crear una lista de tareas más, sino una herramienta que conectara trabajo, dependencias, conocimiento y toma de decisiones dentro del mismo flujo semanal.
La solución
Un sistema operativo interno para coordinar trabajo real.
Project Flow centraliza proyectos, fases, tareas, solicitudes, departamentos, guías, plantillas, actividad y usuarios. Cada vista responde a una pregunta operativa distinta: qué hago hoy, quién está saturado, qué proyecto está en riesgo, qué dependencia falta o qué proceso debemos seguir.
El proyecto empezó como una app cliente con datos locales y evolucionó a una aplicación con backend Express, autenticación real, PostgreSQL, seed inicial, Docker y despliegue preparado para Dokploy.
Producto
Módulos pensados para decidir mejor, no para acumular pantallas.
Inicio personal
Dashboard orientado al foco diario: prioridades, vencidas, bloqueos, solicitudes abiertas, carga semanal y contexto general de la empresa.
Planificación
Vista semanal por personas o por proyectos, con capacidad base, sobrecarga, entregas, bloqueos y replanificación manual de tareas.
Control global
Radar transversal para detectar proyectos, áreas y tareas con más riesgo, filtrando por responsable, departamento, importancia y estado.
Solicitudes
Cola interdepartamental para peticiones, aprobaciones, bloqueos y feedback, con responsables, deadlines, historial y vínculo a tareas.
Guidelines
Base de conocimiento interna con procesos, checklists, políticas, owners, revisión, alcance global o por área y etiquetas.
Plantillas
Biblioteca reutilizable para crear proyectos, tareas, solicitudes y guías con estructura, fases, offsets y criterios ya definidos.
Actividad
Feed de trazabilidad para entender quién creó, actualizó, archivó o desbloqueó trabajo sin reconstruir el contexto por chat.
Usuarios
Panel de administración con usuarios, roles, departamentos y acceso completo, protegido para perfiles con permisos elevados.
Arquitectura
De prototipo local a aplicación persistente.
La parte importante de la migración fue mantener la sensación de workspace rápido mientras los datos pasaban a vivir en una base compartida y cada operación quedaba protegida por la API.
Frontend React como workspace
La interfaz está organizada por rutas operativas: dashboard, trabajo personal, planificación, control, departamentos, proyecto, solicitudes, conocimiento, plantillas, actividad, archivados y usuarios.
Express como API de producto
El servidor sirve el build de Vite y expone endpoints en /api para autenticación, usuarios, departamentos, proyectos, tareas, solicitudes, guidelines, plantillas y actividad.
PostgreSQL como memoria compartida
Las entidades principales viven en tablas propias, con arrays de texto y JSONB para fases, subtareas, historial y payloads de plantillas, además de índices para las consultas frecuentes.
JWT para acceso real
El acceso dejó de ser una selección de usuario en localStorage y pasó a un login con email, bcrypt, token JWT y middleware de autorización.
Seed desde datos de producto
El seed transforma el dataset inicial en departamentos, usuarios, proyectos, tareas, solicitudes, guías y plantillas para arrancar el workspace con contenido útil.
Docker y Dokploy
El proyecto quedó preparado para desplegarse como servicio Node, con variables de entorno para la base de datos, el JWT, el admin inicial y la contraseña del seed.
Modelo de datos
Núcleo relacional, flexibilidad donde de verdad hace falta.
Nueve tablas sostienen el workspace. Lo estable (usuarios, proyectos, tareas, solicitudes) es relacional e indexado; lo que cambia de forma (fases, subtareas, historial, payloads) vive en JSONB.
users · user_departmentsUsuarios con rol y acceso completo, y su pertenencia a uno o varios departamentos mediante una tabla puente M:N.
projectsProyectos con manager, estado, prioridad, importancia y fases. Las fases y los enlaces se guardan como JSONB porque cambian de forma.
tasksTareas con estimación de horas, fechas (start/due/planned), dependencias, subtareas y solicitudes vinculadas. Es la base del planning por capacidad.
requestsSolicitudes interdepartamentales con responsable, prioridad, deadline, si bloquean una tarea e historial completo de la negociación.
guidelinesBase de conocimiento: alcance (global o por área), owner, fecha de revisión, marca de proceso clave y etiquetas.
templatesPlantillas reutilizables cuyo payload JSONB es accionable: puede materializar proyectos, tareas o solicitudes completas.
activitiesFeed de trazabilidad: tipo de entidad, acción, actor, ruta y metadata. Es lo que evita reconstruir el contexto por chat.
Evolución
La herramienta maduró al mismo ritmo que la operativa.
La evolución no fue añadir pantallas por añadir. Cada salto resolvió una limitación concreta: datos locales, falta de memoria compartida, acceso real y un despliegue mantenible.
Prototipo local
Primera versión centrada en validar flujos: pantallas, entidades, filtros y experiencia de trabajo, sin frenar la exploración con infraestructura prematura.
Workspace persistente
Migración a Express y PostgreSQL para que proyectos, tareas, solicitudes, plantillas, usuarios y actividad vivan como memoria compartida.
Acceso y administración
JWT, bcrypt, usuarios, roles y un panel de administración convierten la herramienta en una app interna usable por el equipo, no solo por quien la desarrolló.
Operativa desplegable
Docker, seed, variables de entorno y Dokploy preparan el sistema para convivir con el resto de servicios internos de Growork.
Lo difícil
El reto era convertir el ruido operativo en señales claras.
Un gestor de proyectos puede quedarse en un CRUD muy rápido. Aquí el foco fue otro: calcular el riesgo, mostrar los bloqueos, entender la capacidad, ligar solicitudes a tareas, ordenar fases y acercar el conocimiento al trabajo diario.
Por eso muchas piezas no son vistosas por sí mismas, pero cambian la forma de operar: historial, deadlines relativos, etiquetas semánticas, dependencias, subtareas, owners, permisos y plantillas con payload.
Entidades principales
- →Usuarios con email, hash de contraseña, rol, departamento y acceso completo.
- →Departamentos como eje de visibilidad, color y responsabilidad.
- →Proyectos con manager, estado, prioridad, importancia, archivo y fases en JSONB.
- →Tareas con fechas, esfuerzo, subtareas, dependencias y solicitudes ligadas.
- →Solicitudes con historial, destino, responsable, prioridad y bloqueo opcional.
- →Guidelines, plantillas y actividad como capa de conocimiento y trazabilidad.
Complejidad real
Lo que había que resolver por debajo de la interfaz.
No construir otro tablero bonito
La app necesitaba responder preguntas reales: qué vence hoy, qué está bloqueado, quién está saturado, qué proyecto concentra el riesgo y qué solicitud está frenando una entrega.
Separar trabajo de coordinación
Una solicitud no es una tarea. Puede pedir una aprobación, feedback, datos o un desbloqueo, puede venir de otro departamento y puede bloquear una tarea existente sin convertirse en la tarea principal.
Modelar fases sin encerrar al equipo
Los proyectos pueden tener fases ordenadas, pero las tareas conservan responsable, estado, prioridad, fechas, esfuerzo, dependencias, subtareas y solicitudes vinculadas.
Migrar de localStorage a un sistema persistente
El mayor cambio no fue añadir una base de datos, sino conservar la experiencia fluida del frontend mientras cada acción pasaba por una API y dejaba trazabilidad.
Convertir el conocimiento en parte del flujo
Las guías y las plantillas no viven como documentación decorativa. Aparecen cerca del trabajo para acelerar handoffs, aprobaciones, procesos repetibles y proyectos nuevos.
Decisiones técnicas
Decisiones que hicieron el producto más serio.
JWT en vez de usuario simulado
El workspace dejó de depender de un selector local. El login real permite controlar el acceso, crear usuarios, cambiar contraseñas y proteger todas las rutas de la API.
JSONB solo donde aporta flexibilidad
Fases, subtareas, historial y payloads de plantillas se guardan como JSONB porque cambian más que el núcleo relacional. Usuarios, tareas, proyectos y solicitudes mantienen tablas claras.
Planning por capacidad, no solo por fecha
La vista semanal suma las horas estimadas (estimate) por persona y semana (planned_date) y las cruza con la capacidad base para señalar la sobrecarga. Así la planificación habla de carga real, no solo de calendarios.
Solicitudes como entidad propia
Las dependencias entre áreas quedan trazadas: solicitante, destino, responsable, estado, prioridad, deadline, si bloquea una tarea y qué historial operativo arrastra.
Plantillas con payload accionable
Una plantilla no es solo texto. Su payload JSONB puede crear proyectos con fases y tareas, tareas con estimaciones o solicitudes con prioridad y bloqueo ya predefinidos.
Actividad best-effort
La UI se actualiza rápido y registra la actividad como trazabilidad adicional. Si el log falla, no bloquea el trabajo principal del usuario.
Seguridad y despliegue
Preparado para un uso interno real.
Acceso protegido
Login con email y contraseña, bcrypt para los hashes, JWT con expiración configurable y middleware en las rutas privadas.
Datos centralizados
PostgreSQL sustituye el estado local, con un esquema reproducible, seed y variables de entorno para el entorno de producción.
Operativa administrable
Un usuario con acceso completo puede crear, editar y eliminar usuarios sin tocar la base de datos a mano.
Stack con contexto
Tecnología elegida por utilidad, no por escaparate.
React 19 + Vite 7
Interfaz SPA rápida para un workspace con muchas vistas, modales, drawers, filtros y estados interactivos.
React Router 7
Rutas internas limpias para separar dashboard, planificación, control, proyectos, solicitudes, guías, plantillas y administración.
Tailwind CSS 4
Sistema visual denso y consistente, preparado para superficies de trabajo, tablas, cards, drawers y estados semánticos.
Express 4
Backend pragmático para servir el frontend y exponer una API REST sin sobredimensionar el proyecto.
PostgreSQL + pg
Persistencia relacional para usuarios, proyectos, tareas y solicitudes, con JSONB cuando la estructura necesitaba flexibilidad.
jsonwebtoken + bcryptjs
Autenticación real con contraseñas hasheadas, middleware de protección y token en la cabecera Authorization Bearer.
Docker
Build reproducible: compila Vite, copia el servidor, la API y los scripts de BD, instala dependencias de producción y arranca con Node.
Dokploy
Despliegue pensado para convivir con servicios existentes y una base PostgreSQL compartida mediante variables de entorno.
Lo que demuestra
Producto interno con criterio operativo.
Pensamiento de producto
Cada pantalla existe porque ayuda a priorizar, coordinar, desbloquear o reutilizar trabajo.
Arquitectura pragmática
Frontend rápido, API sencilla, base relacional y JSONB donde tiene sentido mantener la flexibilidad.
Madurez operativa
Autenticación, usuarios, permisos, seed, Docker y despliegue preparado para que la herramienta sobreviva fuera del entorno local.