--- title: "Concert Music Festival: la app que se actualiza sola · Polargate" description: "Un festival de música de verano español tenía el cartel compilado dentro del binario de la app y el backend encerrado en una plataforma no-code." url: https://polargate.ai/es/work/concert-music-festival locale: es publisher: POLARGATE S.L. --- - [Polargate](https://polargate.ai/es) - [Proyectos](https://polargate.ai/es/work) - Concert Music Festival Música en directo y festivales # De un cartel congelado a una app que se actualiza sola Un festival de música de verano español tenía el cartel compilado dentro del binario de la app y el backend encerrado en una plataforma no-code. Polargate rehízo los cimientos en cuatro días, a diez días de empezar la temporada. [Ver el proyecto en vivo](https://cmf.polargate.ai) cmf.polargate.ai En corto Polargate rescató la app oficial de un festival de música español: el cartel estaba compilado dentro del binario de la tienda y el backend vivía en una plataforma no-code que no lo soltaba. En cuatro días migramos 26 tablas, 12 edge functions y 62 usuarios a nuestro propio Supabase, conectamos el WordPress del festival con una sincronización cada 30 minutos y desde entonces publicamos los cambios over the air. 4 días del diagnóstico al backend nuevo funcionando 62 cuentas de usuario migradas conservando sus IDs 37 conciertos sincronizados desde la web en la temporada 2026 30 min intervalo de sincronización entre WordPress y la app 177 países en los que está disponible la app de Android 106 tests unitarios que corren en cada cambio ## El problema El festival ya tenía su app oficial en las dos tiendas, hecha sobre una plataforma no-code. El cartel iba compilado dentro del binario: añadir un artista significaba tocar código y esperar la revisión de Apple y de Google. La app enseñaba un cartel que la web ya había cambiado y faltaba una de las cabezas de cartel. El backend vivía en un proyecto de Supabase que el proveedor no soltaba, las notificaciones push no habían entregado ni un mensaje y quedaban diez días para el primer concierto. ## Qué construimos Polargate encontró la causa raíz y rehízo los cimientos en cuatro días. Movimos todo el backend a un proyecto de Supabase que controlamos nosotros: 31 migraciones, 26 tablas con RLS, 12 edge functions, 62 cuentas de usuario conservando sus IDs, 265 elementos de galería y 603 ficheros de almacenamiento. Reescribimos la capa de contenido para leer el cartel en vivo y escribimos un plugin de WordPress y una edge function que sincroniza cada 30 minutos y se trae imágenes y PDFs a nuestro almacenamiento. La publicación pasó a la nube: Xcode Cloud en iOS, GitHub Actions en Android y actualizaciones over the air para el resto. ## El resultado La temporada 2026 corrió sobre la base nueva. Los 37 conciertos entre el 10 de julio y el 17 de agosto fueron al ritmo de la web oficial sin que nadie tocara código. La app de Android está publicada en 177 países y la de iOS se relanzó y hoy recibe la mayoría de los cambios over the air, sin revisión de tienda. El push de iOS pasó de cero dispositivos registrados en seis semanas a 149 en cuanto añadimos los dos métodos que faltaban en el AppDelegate nativo. El modo de fin de edición se diseñó, se hizo y se desplegó en un día. Stack - Capacitor - React - Vite - TypeScript - Tailwind CSS - shadcn/ui - TanStack Query - Supabase - PostgreSQL - Deno - Vercel - WordPress - GitHub - GitHub Actions - iOS - Android - Firebase - Resend - Vitest - Playwright [cmf.polargate.ai](https://cmf.polargate.ai) ## El contexto Un festival de música de verano en la costa de Cádiz, con temporada de julio a mediados de agosto, tenía su app oficial de iOS y Android hecha sobre una plataforma no-code. El equipo trabaja en WordPress, donde el cartel vive dentro de un plugin de eventos, y daba por hecho que la app iría detrás. No iba. ## Qué encontramos Diagnóstico el 30 de junio de 2026, a diez días del primer concierto: - El cartel estaba escrito a mano en el código y compilado dentro del binario de la tienda. Cada cambio era una versión nueva y una revisión de tienda. - El backend de Supabase pertenecía a la cuenta del proveedor no-code y estaba desconectado de la app en la práctica. - El push nunca había funcionado en iOS: al AppDelegate nativo le faltaban los dos métodos que entregan el token del dispositivo, así que pasaron seis semanas de temporada con cero dispositivos registrados. - El chequeo de TypeScript daba verde porque su configuración no incluía ni un solo fichero. ## Qué construimos Movimos el backend a un proyecto de Supabase que controlamos nosotros y rehicimos el camino del contenido. - Migración en cuatro días: 31 migraciones, 26 tablas con RLS, 12 edge functions, 62 usuarios y 62 perfiles conservando sus IDs, 265 filas de galería, 6 vídeos y 603 ficheros de almacenamiento. - Un plugin de WordPress propio publica la edición vigente en un único endpoint, porque la API estándar de WordPress no devuelve las fechas ni las horas de los eventos. Una edge function lo sincroniza cada 30 minutos, se descarga imágenes y PDFs a nuestro almacenamiento, reintenta cuando el firewall del sitio responde raro y se puede ejecutar dos veces sin duplicar nada. - Publicación automatizada: iOS se compila en Xcode Cloud a partir de una etiqueta de git y se envía a revisión por la App Store Connect API. Android se compila, se firma y se sube a producción en Play desde GitHub Actions. - Actualizaciones over the air con capgo autoalojado en el OTA Hub de Polargate, con canales, porcentaje de despliegue y versión nativa mínima. - Push rehecho de punta a punta: APNs directo en iOS, FCM HTTP v1 en Android, campañas programadas con cron de Postgres, auditoría de envíos, interruptor remoto por plataforma y un cortacircuitos que para tras dos intentos fallidos. ## Cómo funciona hoy El equipo del festival publica en WordPress y la app va detrás en menos de media hora, en las dos tiendas y en la web. React, Vite, TypeScript, Tailwind y shadcn/ui en el front, Capacitor 8 para las cáscaras nativas, Supabase para datos, autenticación, almacenamiento y funciones, Vercel para la web. En cada cambio corren 106 tests unitarios y un test de extremo a extremo, y Sentry y Crashlytics cuentan lo que se rompe. Polargate mantiene la app con una cuota mensual: dudas de contenido, publicaciones en las dos tiendas, respuesta a incidentes y el trabajo estacional de cerrar una edición y abrir la siguiente. [Build →](https://polargate.ai/es/services/build) · [Grow →](https://polargate.ai/es/services/grow) · [Care →](https://polargate.ai/es/services/care) · [Eventos y música en vivo →](https://polargate.ai/es/for/events) FAQ ## Preguntas sobre este proyecto ¿Cuánto se tarda en sacar una app de una plataforma no-code? En esta app de festival fueron cuatro días, del diagnóstico a tener el backend bajo nuestro control, más un envío final a cada tienda. Esquema, edge functions, usuarios, roles, medios y secretos se movieron sin perder datos y los usuarios mantuvieron sus IDs, así que nadie tuvo que registrarse otra vez. El plazo depende de cuánto viva dentro de la cuenta del proveedor, y eso es justo lo que mide el Discovery Sprint de pago de Polargate. ¿Se puede conectar la app con nuestro WordPress o con nuestra ticketera? Sí. Aquí el equipo del festival sigue trabajando en WordPress y un plugin que escribimos nosotros publica la edición vigente en un único endpoint, porque la API estándar de WordPress no devuelve fechas ni horas de los eventos. Una edge function lo trae cada 30 minutos y copia imágenes y PDFs a nuestro almacenamiento, así que la app sigue funcionando aunque WordPress no lo haga. Con las ticketeras depende del acceso a API que conceda el proveedor. ¿Podemos actualizar la app sin pasar cada vez por la revisión de Apple? La mayoría de las veces, sí. Todo lo que vive en la capa web, textos, pantallas, maquetación y reglas de contenido, se publica over the air por el OTA Hub de Polargate, con canales, porcentaje de despliegue y versión nativa mínima. Los cambios nativos, los permisos nuevos o los plugins nuevos siguen necesitando una publicación en tienda, automatizada desde una etiqueta de git. En esta app el over the air está activo en iOS y Android se mantiene en publicaciones de tienda tras un incidente. ¿Polargate acepta una app hecha por otra agencia o con una herramienta no-code? Sí, así empezó este proyecto. Polargate arranca con un Discovery Sprint de pago: leemos el código, el backend y las cuentas de las tiendas, y contamos qué está bien, qué bloquea el proveedor anterior y qué cuesta arreglarlo. Ese informe es tuyo, sigas o no con nosotros. A partir de ahí el backend deja de estar en una plataforma que puede negarse a entregarlo. ¿Cuánto cuesta mantener viva una app de festival después del lanzamiento? Esta app se mantiene con una cuota desde 850 euros al mes, que cubre dudas de contenido, publicaciones en las dos tiendas, respuesta a incidentes y el trabajo estacional de cerrar una edición y abrir la siguiente. Lo que se construye se presupuesta aparte: el sistema de descarga, con enlace inteligente, banner nativo y QR para imprimir, fueron 350 euros cerrados. Polargate pone precio al mantenimiento por la superficie que cuida, no por número de tickets. INITIATE ## Arranca el motor Cuéntanos qué estás construyendo en unas pocas preguntas cortas. Un ingeniero senior responde por escrito en 48 horas laborables con una primera lectura de alcance, plazos y precio. [Empieza tu proyecto](https://polargate.ai/es/start) · [Habla con nosotros](https://polargate.ai/es/start#static-brief-heading)