PATAgenda
Agenda de sumarios docentes
papel y Excel sin trazabilidad.
sistema web con cero vencimientos olvidados
"Desarrollo de una agenda full-stack que modela con precisión el lenguaje legal del Ministerio de Educación priorizando la privacidad de datos sensibles."
El punto de partida del desafío
Hurgando bajo la superficie: ¿Qué investigué?
Analicé en profundidad el flujo de trabajo diario de la clienta durante varias semanas. Descubrí que la mayoría de los gestores de tareas asumen flujos lineales y abstractos como "to-do", "in progress", "done". Pero un expediente sumarial sigue un ciclo de vida regulado con estados legales específicos y vencimientos fatales que, si se incumplen, tienen consecuencias jurídicas reales. No es un tablero Kanban. Es un calendario de obligaciones legales. Evalué opciones de infraestructura: los servicios cloud como Firebase o Supabase habrían acelerado el desarrollo, pero implicaban almacenar datos disciplinarios en servidores de terceros. La solución tenía que ser deployable pero con acceso restringido y controlado.
"La adopción de software no falla por motivos técnicos. Falla cuando el sistema no representa la forma de pensar del usuario. El modelo de datos debía hablar con precisión el lenguaje del Ministerio de Educación. En lugar de modelar estados abstractos como "pendiente" o "completado", diseñé conceptos de dominio legales reales: Sumario Ordinario, Sumario Abreviado, Mediación, Sobreseimiento, Sanción Grave, cada uno con sus plazos, vencimientos y restricciones específicas. Diseñar para una única usuaria también fue liberador, eliminó la necesidad de gestionar roles complejos o accesos concurrentes, y permitió enfocar toda la energía en pulir un producto que realmente le funciona."
Comprender este pilar transformó por completo la dirección táctica del proyecto, permitiendo depurar el ruido innecesario y enfocarse en valor estricto.
Análisis de compromisos: opciones sobre la mesa
Construir software a medida requiere evaluar escenarios honestamente. Ninguna arquitectura es perfecta, cada decisión tiene un precio:
Gestores genéricos en la nube (Notion, Trello)
Rápido de configurar y sin desarrollo. Pero violaba los requisitos de privacidad al quedar datos sensibles en servidores de terceros, y obligaba a la clienta a adaptar procesos legales complejos a abstracciones genéricas que no representan su realidad.
Sistema cloud propio (Supabase, Firebase)
Menor complejidad de infraestructura y backups automatizados. Pero implicaba almacenar información disciplinaria confidencial de docentes en servidores externos, lo cual era inaceptable desde lo normativo y lo ético, independientemente de las promesas de seguridad del proveedor.
Aplicación full-stack autohosteada
Era el plan original. Los datos residirían exclusivamente en el equipo local bajo control directo de la clienta, con cero costos de SaaS. Pero la contra cara era perder acceso remoto y movilidad: solo podría usar el sistema desde esa computadora. Finalmente optamos por deployar en Vercel para ganar flexibilidad.
Diseño single-user sin concurrencia
Simplificó radicalmente la arquitectura eliminando roles, permisos, bloqueos de escritura y conflictos de edición. Permitió enfocar todo el esfuerzo en pulir la experiencia para una usuaria específica. Pero rigidizó el modelo: escalar a múltiples inspectores requeriría cambios estructurales profundos.
Seguridad con JWT httpOnly + rate limiting
Almacenar el token en cookie httpOnly, inaccesible desde JavaScript, mitigó el riesgo de XSS. El rate limiting previno abusos. No se implementó OAuth ni autenticación de dos factores porque, para una aplicación local de un único usuario, habría sido sobrediseñar sin beneficio real de seguridad.
La Decisión: El camino elegido
LO QUE FUNCIONÓ DE VERDAD
Lo que mejor funcionó fue que el sistema hablara exactamente el mismo idioma que la clienta desde el primer día: no hubo que traducir conceptos del dominio legal a abstracciones de software ni forzar una curva de aprendizaje. La dispersión de información —su mayor dolor cotidiano— quedó resuelta en un solo lugar, y el acceso desde el celular cubrió el uso fuera de la oficina, que era el que se caía siempre. La clienta sigue usándolo como sistema de trabajo.
LIMITACIONES Y COMPROMISOS
Al estar deployada en la nube, los datos sensibles ya no residen exclusivamente en el equipo de la clienta, aunque el acceso está restringido por autenticación y las conexiones son sobre HTTPS. El hosting de PostgreSQL y Vercel tiene un costo mensual que antes no existía. Al depender de conexión a internet, si hay cortes de red el sistema queda inaccesible. La aplicación está modelada para una sola persona; escalarla para un equipo de inspectores requeriría reestructurar profundamente el modelo de datos y la gestión de permisos.
DE LA BITÁCORA PERSONAL DE GONZALO: ¿QUÉ HARÍA DIFERENTE HOY?
"Implementaría backups automatizados del PostgreSQL para tener copias de seguridad sin depender de procesos manuales."
Anotación retrospectiva posterior al lanzamiento