Skip to content
POLARGATE
Live music and festivals

From a frozen line-up to an app that updates itself

A Spanish summer music festival had its line-up compiled into the app binary and its backend locked inside a no-code platform. Polargate rebuilt the foundation in four days, ten days before the season started.

Visit the live site
Home screen of the Concert Music Festival web app: the festival name and Sancti Petri, Chiclana de la Frontera, Cádiz over a dim stage, with a tab bar below.
cmf.polargate.ai
4
days from diagnosis to the new backend running
62
user accounts migrated with their IDs preserved
37
shows synced from the website in the 2026 season
30 min
sync interval between WordPress and the app
177
countries where the Android app is available
106
unit tests running on every change

The problem

The festival already had an official app in both stores, built on a no-code platform. The line-up was compiled into the binary, so adding an artist meant editing code and waiting for Apple and Google to review a new release. The app showed a line-up the website had already changed, and one headline act was missing entirely. The backend lived in a Supabase project the vendor would not hand over, push notifications had never delivered a single message, and the first show was ten days away.

What we built

Polargate found the root cause and rebuilt the foundation in four days. We moved the whole backend to a Supabase project we control: 31 migrations, 26 tables with row level security, 12 edge functions, 62 user accounts with their IDs intact, 265 gallery items and 603 storage files. We rewrote the content layer so the line-up is read live, and wrote a WordPress plugin plus an edge function that syncs every 30 minutes and copies images and PDFs into our own storage. Releases moved to the cloud: Xcode Cloud on iOS, GitHub Actions on Android, over the air updates for the rest.

The outcome

The 2026 season ran on the new stack. 37 shows between 10 July and 17 August stayed in step with the official website without anyone touching code. The Android app is live in 177 countries, and the iOS app was relaunched and now takes most changes over the air, with no store review. iOS push went from zero registered devices in six weeks to 149 once we added the two missing methods in the native app delegate. End of edition mode was designed, built and deployed in a single day.

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

The context

A summer music festival on the coast of Cádiz, with a season running from July to mid August, had an official app for iOS and Android built on a no-code platform. The team works in WordPress, where the line-up lives inside an events plugin, and assumed the app would follow. It did not.

What we found

Diagnosis on 30 June 2026, ten days before the first show:

  • The line-up was hardcoded in the source and compiled into the store binary. Every change was a new release and a store review.
  • The Supabase backend belonged to the no-code vendor's account and was effectively disconnected from the app.
  • Push had never worked on iOS. The native app delegate was missing the two methods that hand over the device token, so six weeks of season went by with zero registered devices.
  • The TypeScript check reported green because its configuration matched no files at all.

What we built

We moved the backend to a Supabase project we control and rebuilt the content path.

  • Migration in four days: 31 migrations, 26 tables with row level security, 12 edge functions, 62 users and 62 profiles with their IDs preserved, 265 gallery rows, 6 videos, 603 storage files.
  • A WordPress plugin we wrote exposes the current edition through a single endpoint, because the standard WordPress API does not return event dates and times. A Supabase edge function syncs it every 30 minutes, downloads images and PDFs into our storage, retries when the site firewall answers oddly, and is safe to run twice.
  • Automated releases: iOS builds in Xcode Cloud from a git tag and submits itself through the App Store Connect API. Android builds, signs and uploads to Play production from GitHub Actions.
  • Over the air updates with self-hosted capgo through Polargate's OTA Hub, with channels, rollout percentage and a minimum native version gate.
  • Push rebuilt end to end: APNs directly on iOS, FCM HTTP v1 on Android, campaigns scheduled with Postgres cron, delivery auditing, a remote kill switch per platform and a circuit breaker that stops after two failed attempts.

How it runs now

The festival team publishes in WordPress and the app follows within half an hour, on both stores and on the web. React, Vite, TypeScript, Tailwind and shadcn/ui on the front, Capacitor 8 for the native shells, Supabase for data, auth, storage and functions, Vercel for the web. 106 unit tests and one end to end smoke test run on every change, and Sentry and Crashlytics report what breaks. Polargate keeps the app on a monthly maintenance retainer: content questions, store releases on both platforms, incident response, and the seasonal work of closing one edition and opening the next.

Build →Grow →Care →Events and live →
FAQ

Questions about this project

How long does it take to move an app off a no-code platform?
For this festival app it took four days, from diagnosis to a backend under our control, plus one final submission on each store. Schema, edge functions, users, roles, media and secrets moved without data loss, and users kept their IDs so nobody had to register again. The time depends on how much sits inside the vendor's account, which is exactly what Polargate measures in a paid Discovery Sprint.
Can you connect the app to our WordPress or to our ticketing system?
Yes. Here the festival team keeps working in WordPress, and a plugin we wrote exposes the current edition through one endpoint, because the standard WordPress API does not return event dates and times. An edge function pulls it every 30 minutes and copies images and PDFs into our own storage, so the app keeps working even when WordPress does not. Ticketing platforms depend on the API access the vendor grants.
Can we update the app without an Apple review every time?
Most of the time, yes. Anything living in the web layer, texts, screens, layouts and content rules, ships over the air through Polargate's OTA Hub, with channels, a rollout percentage and a minimum native version gate. Native changes, new permissions or new plugins still need a store release, which is automated from a git tag. On this app over the air is active on iOS, and Android stays on store releases after an incident.
Do you take over an app that another agency or a no-code tool built?
Yes, that is how this project started. Polargate begins with a paid Discovery Sprint: we read the code, the backend and the store accounts, and report what is solid, what is blocked by the previous supplier and what it costs to fix. You keep that report whether or not you continue with us. From there the backend no longer sits in a platform that can refuse to hand it over.
What does it cost to keep a festival app running after launch?
This app runs on a maintenance retainer from 850 euros a month, covering content questions, releases on both stores, incident response and the seasonal work of closing one edition and opening the next. Build work is quoted separately: the download system, with its smart link, native banner and print QR codes, was a fixed 350 euros. Polargate prices a retainer by the surface it maintains, not by ticket volume.
INITIATE

Start the engine

Tell us what you are building in a few short questions. A senior engineer answers in writing within 48 business hours, with a first take on scope, timeline and price.

Start your project Talk to us