Saltar al contenido principal
Volver a proyectos
En producción diciembre de 2024 — enero de 2025 Diseño, desarrollo y deploy

Full Day Gestión de TI

Landing y panel administrativo para un evento académico de la UNT con 100 registros en 5 semanas.

Captura de la landing de Full Day Gestión de TI: sección principal con el título del evento, la fecha y los botones de registro
~100
Registros
~95
Asistentes
8
Módulos admin
  • Laravel
  • Filament
  • Tailwind CSS
  • Vite
  • Pest
  • MySQL
  • Axios

Problema

El curso de Gestión de TI de la Escuela de Ingeniería de Sistemas de la UNT necesitaba un evento académico que reuniera a estudiantes, profesionales del PMI Lima y especialistas COBIT/ITIL en un solo sábado. La parte visible (sitio público con info del evento) era el 30% del trabajo; el 70% era la operación: capturar registros con DNI/teléfono/especialidad, validar duplicados, comunicar cambios, controlar capacidad del auditorio.

Sin admin propio el equipo organizador habría dependido de spreadsheets compartidas, lo que multiplica errores cuando los registros suben de 50.

Aproximación

Stack monolítico Laravel + Filament + MySQL para que el admin y la landing compartieran modelo de datos sin sincronización manual. Tailwind para controlar la jerarquía visual del countdown y la agenda (el botón “Regístrate” debe leerse desde el final de la página). Pest para tests sobre las validaciones del formulario, que era el camino crítico del evento.

Deploy en el VPS de jabss.dev como subdominio, aprovechando el Nginx multi-tenant ya configurado.

Decisiones

  1. Filament sobre admin Laravel custom (o Nova): con 5 semanas de timeline y 8 entidades CRUD (registros, ponentes, charlas, sponsors, sliders, anuncios, config countdown, config general), Filament permitía generar resources con validaciones tipadas en horas. Nova exigía licencia comercial; un admin custom hubiera consumido las 5 semanas solo en CRUD.

  2. Pest sobre PHPUnit: la sintaxis it('rechaza DNIs duplicados', ...) lee como spec de negocio y baja la fricción a la hora de escribir feature tests bajo presión. Paralelización por defecto y datasets en una línea ayudaron a probar las combinaciones de campos del registro sin boilerplate.

  3. MySQL sobre PostgreSQL: el VPS ya servía otros sitios sobre MySQL preinstalado, y el dominio (registros simples con FKs lineales) no necesitaba ventajas de PostgreSQL. Mantener un solo motor de BD bajó el costo operativo del subdominio.

Resultado

  • ~100 registros capturados en 5 semanas de campaña, ~95 asistentes confirmados el día del evento (95% de conversión).
  • Cero downtime durante las 12 horas del evento gracias al tier de Lightsail + caching de Nginx.
  • Admin con dashboard que mostraba en tiempo real: registros pendientes/aceptados/rechazados, total de ponentes, sponsors activos, tasa de aceptación y registros recientes — el equipo organizador no tocó la base de datos manualmente ni una vez.