De la cuarentena a 240K usuarios
Empecé ComediaPlay cuando el entretenimiento en vivo se detuvo durante la pandemia. Diseñé, construí y operé casi todo el producto yo solo hasta cerrarlo en agosto de 2026; la mayor parte de la actividad se concentró hasta 2024.
- Usuarios
- ~240K
- Accesos digitales pagados
- ~400K
- Volumen transaccional
- ~US$3.5M
- Usuarios concurrentes en pico
- ~10K
ComediaPlay nació porque el entretenimiento en vivo se detuvo.
Durante la pandemia, comediantes, productores y audiencias de pronto necesitaron una forma de seguir haciendo shows online. Construí una plataforma para vender y acceder a shows de comedia, eventos digitales y estrenos de cine.
Terminé manejando casi todo yo solo: producto, diseño, desarrollo, infraestructura y operaciones. Contabilidad fue básicamente la única parte que no manejé.
Resumen
- Período
- Abril de 2020 – agosto de 2026
- Producto
- Plataforma de entretenimiento online para shows de comedia, eventos digitales y estrenos de cine
- Stack
- WordPress + WooCommerce core · PHP · SQL · Redis · servicios Rust WebSocket · nodos VPS con balanceo de carga · APIs de LLM (2023–24)
Un acceso pagado es una entrada comprada a un show, evento o estreno. Un mismo usuario podía comprar varios, por eso las cifras siempre se muestran por separado.
Pantallas reales, 2021: home y una página de evento. El contenido mostrado pertenece a los artistas.
Empezó simple. No lo reescribí.
La primera versión usó WordPress y WooCommerce.
Eso fue intencional. Necesitaba poner un producto real en manos de la gente rápido, y reconstruir comercio, gestión de contenido y administración desde cero habría sido un pésimo uso del tiempo.
WordPress funcionó bien, hasta que algunas partes del producto empezaron a necesitar cosas muy distintas de él. Una reconstrucción completa habría detenido el trabajo de producto y puesto en riesgo un negocio que ya procesaba transacciones reales. Así que mantuve WordPress donde era útil y fui separando gradualmente las cargas de trabajo que se estaban convirtiendo en cuellos de botella.
Los pasos están en el orden en que ocurrieron. Cada uno fue una respuesta a un problema de carga, latencia u operación que la etapa anterior había expuesto.
Los picos de tráfico cambiaron la arquitectura
Los estrenos no eran tráfico de ecommerce normal.
Miles de personas podían llegar en una ventana de tiempo muy corta, autenticarse, acceder al contenido y empezar a interactuar casi al mismo tiempo.
Aislé la base de datos, puse la aplicación detrás de un balanceador de carga y agregué múltiples nodos VPS para que la capa web pudiera escalar horizontalmente. Redis se convirtió en infraestructura compartida entre esos nodos.
Esa arquitectura llegó a manejar picos de aproximadamente 10K usuarios concurrentes durante un estreno de alta demanda.
El tiempo real no pertenecía dentro de WordPress
El chat y el control de sesión tenían otro problema: las conexiones se mantenían abiertas.
No quería miles de conexiones WebSocket persistentes compitiendo con el checkout, la autenticación y el acceso a contenido.
Así que moví el trabajo de tiempo real a servicios livianos escritos en Rust.
Lo importante no era Rust en sí. Era poder escalar el tiempo real de forma independiente al resto del producto.
El control de acceso también se movió ahí. El contenido podía verse en un dispositivo a la vez por cuenta, una regla indicada en cada página de evento y en los términos, y la capa de tiempo real podía aplicarla sin sumar más carga a la aplicación principal. Escalar también hizo que algunos supuestos antiguos fueran menos aceptables, así que modernicé partes del stack de autenticación, incluyendo mover el hashing de credenciales a Argon2id.
WordPress se quedó. El frontend cambió a su alrededor.
Tampoco quería una reescritura del frontend solo porque el producto necesitara interacciones más ricas.
En cambio, fui introduciendo gradualmente islas dinámicas donde la experiencia realmente se beneficiaba de comportamiento del lado del cliente, y endpoints livianos para las acciones simples y frecuentes de clientes y creadores que no necesitaban que respondiera todo el stack de la aplicación. WordPress siguió haciendo lo que hacía bien, CMS, comercio y administración, mientras las piezas más interactivas podían evolucionar por separado.
Fue menos elegante que partir de un diagrama de arquitectura en blanco. Fue mucho más seguro para un producto que la gente ya estaba pagando por usar.
El soporte también se movió al reproductor: un panel de soluciones rápidas para los minutos antes de que empiece un show, cuando nadie tiene tiempo de abrir un ticket.
La IA generativa llegó después
ComediaPlay no partió como un producto de IA.
Empecé a agregar flujos de trabajo de IA generativa en 2023–2024, cuando los modelos se habían vuelto lo suficientemente útiles como para resolver problemas reales de producto y operación.
Convertir métricas en consejos útiles
Los creadores ya tenían datos. El problema era que los números todavía había que interpretarlos.
Construí endpoints que calculaban y exponían métricas de producto y negocio, y luego convertí esas métricas en contexto estructurado y legible antes de enviarlas a un modelo a través de una API.
El modelo no calculaba los números.
Eso lo hacía la aplicación primero.
El modelo leía ese contexto y lo convertía en explicaciones y recomendaciones personalizadas para los creadores.
Esa separación me importaba: el sistema seguía siendo la fuente de verdad, mientras el modelo se encargaba de la interpretación y la comunicación.
Escribir páginas de evento sin partir de cero
La publicación de eventos tenía otro paso repetitivo: escribir descripciones útiles a partir de información que ya existía en la plataforma.
Empecé a usar los datos estructurados del evento como contexto para que el modelo generara o completara descripciones orientadas a SEO.
El creador seguía controlando qué se publicaba.
Cierre de la plataforma
La mayor parte de la actividad y los resultados de ComediaPlay se concentró hasta 2024. Las ventas continuaron a menor volumen hasta fines de 2025. En 2026 no se agregaron nuevos eventos ni contenidos, y cerré definitivamente la plataforma en agosto de 2026.
Cambió cómo pienso el diseño de producto. Un problema de checkout podía convertirse en un problema de infraestructura, y una regla de licenciamiento en un problema de arquitectura de sesión. Dejé de pensar la interfaz como el producto. El producto era todo el sistema detrás de la experiencia.