Caso de estudio

Dinastía Dorada 2026 · El Legado

Plataforma completa de invitación, acreditación y control de acceso para una gala de 1.848 personas. Del formulario de confirmación al escáner de QR en la puerta, incluyendo el CRM del organizador, el chat de WhatsApp y las campañas masivas. Desarrollada y operada en vivo por una sola persona.

La plataforma es privada del evento y maneja datos personales de los asistentes; aquí se describe solo la arquitectura, las decisiones técnicas y los resultados.

2026Desarrollo full-stack y operación en vivo

Next.js 16React 19TypeScriptNeonPostgreSQLTailwind CSSMotionWhatsApp Cloud APIBrevoPlaywrightVercel

01 · El encargo

De una invitación digital a un sistema de acceso

Dinastía Inc. organiza una gala anual de la industria musical. La edición 2026 esperaba cerca de 1.800 asistentes entre artistas, prensa, empresarios e invitados, con tres niveles de acceso que determinan por dónde y a qué hora entra cada persona: Oro y Diamante por alfombra roja en franjas horarias distintas, Platino por accesos laterales.

El encargo inicial era una invitación digital. Terminó siendo el sistema completo: registro, base de datos, panel de gestión, autoedición del invitado, generación y distribución de pases con QR firmado, escáner de puerta, monitor de ingresos en vivo y un canal bidireccional de WhatsApp — más la operación de todo eso durante la noche del evento.

Invitación→Acreditación→Puerta→Monitor en vivo

▍

02 · Arquitectura

Una sola aplicación, sin caché que mienta

Aplicación única en Next.js 16 (App Router) desplegada en Vercel, con Postgres serverless en Neon. Todas las páginas que tocan datos son dinámicas: no hay caché que pueda mostrar un pase o un aforo desactualizado en la puerta.

Trece rutas cubren los tres públicos del sistema: el invitado (carta, autoedición y pase), el organizador (CRM, chat de WhatsApp y monitor de ingresos) y el staff de puerta (escáner de cámara). Los únicos servicios externos son WhatsApp Cloud API para mensajería y Brevo para correo transaccional.

Invitado→Next.js 16 · Vercel→Neon Postgres→Organizador y staff

03 · Los pases

Un QR firmado que no lleva nada sensible

Cada pase es un token firmado con HMAC-SHA256. El QR codifica la URL de la puerta con ese token; en el código no viaja ningún dato personal, solo un identificador verificable. Un pase puede cubrir a varias personas: el titular más sus acompañantes, cada uno con su propia categoría de acceso.

Hay dos vías de acceso al pase: el enlace con token que se envía por WhatsApp y correo, o el inicio de sesión con correo y teléfono, que muestra todos los pases de esa credencial — pensado para mánagers con varios artistas. Las bandas entran con un solo QR para todo el combo; la más grande llegó a 20 personas.

Token HMAC→QR→Cámara del staff→Ingreso marcado

04 · Seguridad

Datos de 1.848 personas y una puerta física

El sistema maneja datos personales de 1.848 personas y controla el acceso físico a un recinto lleno. El panel pasó de una clave en la URL a inicio de sesión con cookie firmada —HttpOnly, Secure, SameSite y expiración—, de modo que la clave nunca viaja en la URL ni queda guardada en la cookie.

El webhook de Meta valida la firma contra el App Secret y en producción es fail-closed: sin secreto configurado se rechaza todo POST, para que nadie que descubra la URL pueda inyectar mensajes falsos al chat. Cada guardado revalida que el registro pertenezca a la credencial de la sesión, y el cierre de la autoedición se aplica en la Server Action, no solo ocultando el formulario.

Cookie firmada·Webhook verificado·Aislamiento por credencial

05 · Datos

Tres fuentes, cuatro formas de escribir el mismo nombre

La parte menos visible fue la que más tiempo consumió. Los datos llegaban de tres fuentes —formulario web, hojas de cálculo de las bandas y listas por WhatsApp— con duplicados, tildes inconsistentes, cédulas escritas en el campo del teléfono y la misma persona registrada de cuatro maneras distintas.

Se construyeron 14 herramientas de línea de comandos para respaldo, auditoría, deduplicación, fusión, categorización masiva y envíos por tandas. Ninguna operación destructiva se ejecutó sin respaldo previo: se generaron 13 respaldos completos durante el proyecto. Ese hábito fue lo que permitió revertir el error más costoso de todos.

Formulario+Hojas de cálculo+WhatsApp→Una sola base

06 · Comunicaciones

Cinco campañas masivas, cero envíos fallidos

Toda la distribución de pases y avisos se hizo desde el sistema, sin herramientas de terceros para campañas. Se usó WhatsApp Cloud API de Meta directamente, sin intermediario, con 11 plantillas aprobadas y clasificadas deliberadamente como utility en vez de marketing: categoría más barata y con mejor entrega para mensajes transaccionales.

La plantilla del pase lleva el token de cada invitado como parámetro del botón, así que un mismo mensaje aprobado entrega un QR distinto a cada quien. Los envíos masivos son reanudables: registran cada destinatario entregado, con reintentos y espera progresiva, para retomar exactamente donde quedaron si la red falla a mitad de tanda. El correo va por Brevo, agrupado por dirección, de modo que un mánager con varios artistas recibe un solo correo con todos sus pases.

11 plantillas→Envío reanudable→0 fallidos

07 · Rendimiento

El costo de animar cada fila

Tres superficies del panel se degradaron al crecer la base, todas por la misma causa: animar cada fila con Framer Motion dentro de un contenedor de presencia. A escala de cientos o miles de filas, cualquier cambio de estado obliga a reevaluar y reanimar la lista completa.

La tabla del CRM pasó de ~424 ms por tecla a ser fluida con más de 900 registros usando filas memoizadas y valores diferidos. El chat de WhatsApp pasó de congelarse a cargar 237 conversaciones en 260 ms con una sola consulta agregada. El monitor de ingresos pasó de no cargar en el teléfono a responder en 437 ms con 1.800 personas. Todo se verificó con un servidor de pruebas sembrado a escala real y un navegador headless emulando un teléfono — no con estimaciones.

424 ms por tecla→Filas memoizadas→Fluido con 900+

08 · La noche

Tres incidencias en producción, con el evento en curso

Con el evento ya empezado seguían llegando invitados de último minuto —grupos completos agregados durante la tarde y la noche, cada uno verificado contra duplicados y con su QR enviado al instante— mientras se resolvían incidencias en producción.

El monitor de ingresos devolvía HTTP 500 justo al empezar el ingreso: Neon entrega las marcas de tiempo como objetos de fecha, no como texto, y el orden del feed usaba una comparación de cadenas que no existe sobre fechas. Solo se disparaba con dos o más personas ya adentro, por eso ninguna prueba previa lo encontró. Se corrigió normalizando en la capa de datos, por donde pasan todas las lecturas — no en la vista.

HTTP 500→Cookie forjada para medir→Causa raíz

09 · Resultados

1.848 acreditados, cero pérdidas de datos

1.848 personas acreditadas en 902 pases, sin ningún registro sin categoría al cierre. 770 ingresos marcados por escáner durante la noche, cero envíos fallidos definitivos en las cinco campañas masivas y cero pérdidas de datos: las 24 personas afectadas por el error de deduplicación se recuperaron íntegras, con sus QR originales intactos. En la auditoría final, de 945 acompañantes ninguno quedó asignado al pase equivocado.

El aprendizaje de fondo: sin un identificador único, la identidad recae en el nombre — y el nombre miente. El próximo formulario pide la cédula como campo obligatorio, que convierte un problema difuso en una comparación exacta y se valida contra el documento en la puerta.

1.848 acreditados·902 pases·770 ingresos

Arrastra, usa las flechas o el teclado (← →) para recorrer este caso.