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.
- 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
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.
Preguntas sobre este proyecto
¿Cuánto se tarda en sacar una app de una plataforma no-code?
¿Se puede conectar la app con nuestro WordPress o con nuestra ticketera?
¿Podemos actualizar la app sin pasar cada vez por la revisión de Apple?
¿Polargate acepta una app hecha por otra agencia o con una herramienta no-code?
¿Cuánto cuesta mantener viva una app de festival después del lanzamiento?
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.