Volver a Plataformas Completas
En producciónIndividual con sprintsGitHub

Eventyn

Plataforma de invitaciones digitales en producción. Un asistente de IA arma la invitación conversando con el usuario, las plantillas se renderizan con los datos de cada evento y los invitados confirman desde el celular.

Ver la app funcionando

Eventyn — recorrido por la plataforma en producción — subí el volumen para escuchar la narración

> Sobre el proyecto

Eventyn es una plataforma de invitaciones digitales que está funcionando hoy. El usuario crea la invitación de su evento, elige una plantilla, la personaliza y comparte un enlace; los invitados la abren desde el celular, ven toda la información y confirman si van a asistir. Se usó en eventos reales que ya pasaron, que es la mejor prueba que le puedo pedir a algo que construí.

Lo distinto está en cómo se crea la invitación. En vez de un formulario largo que nadie quiere llenar, hay un asistente conversacional con Azure OpenAI que va preguntando: cómo se llama el evento, cuándo es, dónde, quiénes son los protagonistas. El usuario responde en lenguaje natural y el formulario se completa solo mientras conversa. Si falta un dato, lo pide; si le piden algo que la plantilla elegida no soporta, lo dice de frente en vez de prometerlo. Ese detalle —que el asistente conozca los límites de lo que está armando— fue de las cosas que más iteré.

Las plantillas no son páginas fijas. Son plantillas HTML con variables que se resuelven en el servidor con Handlebars, los recursos viven en almacenamiento de Azure detrás de una CDN, y la invitación final se compone en el momento con los datos de ese evento en particular. Sobre esa base se activan secciones extra —galería de fotos, itinerario del evento, dedicatorias— que se insertan dinámicamente sin tocar la plantilla original.

Son tres piezas trabajando juntas. La web pública en Angular 21, donde el usuario crea y administra sus invitaciones y donde los invitados responden. La API en Node.js y Express, que maneja invitaciones, respuestas, plantillas, generación de recursos y el canal de atención al cliente. Y una app móvil en Flutter que uso para administrar la plataforma desde el celular sin depender de estar frente a una computadora.

Acá me tocó todo el ciclo sin ayuda: el modelo de datos en Firestore, la API, la interfaz, la app móvil, el despliegue en Azure y las correcciones que fueron apareciendo con gente real usándola en la fecha de su evento, que es cuando no hay margen para que algo falle.

Funcionalidades

  • Asistente conversacional con IA que completa la invitación mientras el usuario conversa
  • Plantillas HTML dinámicas renderizadas en el servidor con los datos de cada evento
  • Secciones extra activables: galería de fotos, itinerario del evento y dedicatorias
  • Vista previa en tiempo real mientras se edita la invitación
  • Enlace público único por invitación, pensado para abrirse desde el celular
  • Confirmación de asistencia de los invitados con conteo en vivo en el panel
  • Lista de invitados con validación de acceso a la invitación
  • Panel del usuario con todas sus invitaciones y el estado de cada una
  • Generación de imágenes de vista previa de las invitaciones desde el servidor
  • Recursos alojados en Azure Blob Storage y servidos por CDN
  • Notificaciones por correo desde la plataforma
  • Canal de atención al cliente con clasificación automática por prioridad
  • App móvil en Flutter para la administración de la plataforma

Stack técnico

Web

Angular 21TypeScriptAngular MaterialRxJSGSAPReactive Forms

API

Node.jsExpress 5HandlebarsPuppeteerNodemailerREST

Base de datos

FirebaseCloud FirestoreFirebase Admin SDKFirebase Auth

IA

Azure OpenAI GPT-4oAsistente conversacional con estado

Móvil

FlutterDartArquitectura modular

Nube y despliegue

Azure Static Web AppsAzure Blob StorageAzure CDNAzure FunctionsDocker

Organización

Metodología

Individual con sprints

Duración sprint

1 semana

Control de versiones

GitHub

Producto propio, construido solo de principio a fin. Trabajé con sprints cortos de una semana y un backlog priorizado por lo que hacía falta para el siguiente evento real, con criterio de aceptación escrito antes de empezar cada feature. Cada iteración terminaba desplegada y probada con un usuario usándola de verdad, y lo que salía mal ahí entraba primero en el sprint siguiente.

Sprints propiosBacklog priorizadoCriterios de aceptación por featurePruebas con usuarios realesDespliegue continuo
Ver todos los proyectos de Plataformas Completas
ROBO