Van een bevroren line-up naar een app die zichzelf bijwerkt
Een Spaans zomerfestival had de line-up gecompileerd in de app-binary en de backend opgesloten in een no-codeplatform. Polargate bouwde het fundament in vier dagen opnieuw, tien dagen voor het seizoen begon.
- 4
- dagen van diagnose tot de nieuwe backend draaide
- 62
- gebruikersaccounts gemigreerd met behoud van hun IDs
- 37
- optredens gesynchroniseerd vanaf de website in seizoen 2026
- 30 min
- synchronisatie-interval tussen WordPress en de app
- 177
- landen waar de Android-app beschikbaar is
- 106
- unittests die bij elke wijziging draaien
Het probleem
Het festival had al een officiële app in beide stores, gebouwd op een no-codeplatform. De line-up zat gecompileerd in de binary: een artiest toevoegen betekende code aanpassen en wachten op de review van Apple en Google. De app toonde een line-up die op de website allang was gewijzigd en één headliner ontbrak volledig. De backend stond in een Supabase-project dat de leverancier niet vrijgaf, pushberichten hadden nog nooit iets afgeleverd en het eerste optreden was over tien dagen.
Wat we bouwden
Polargate vond de hoofdoorzaak en bouwde het fundament in vier dagen opnieuw. We verhuisden de hele backend naar een Supabase-project dat wij beheren: 31 migraties, 26 tabellen met row level security, 12 edge functions, 62 gebruikersaccounts met behoud van hun IDs, 265 galerij-items en 603 opslagbestanden. We herschreven de contentlaag zodat de line-up live wordt gelezen, en schreven een WordPress-plugin plus een edge function die elke 30 minuten synchroniseert en afbeeldingen en pdf's naar onze eigen opslag kopieert. Releases gingen naar de cloud: Xcode Cloud op iOS, GitHub Actions op Android, over the air voor de rest.
Het resultaat
Het seizoen 2026 draaide op de nieuwe basis. 37 optredens tussen 10 juli en 17 augustus liepen gelijk met de officiële website zonder dat iemand code aanraakte. De Android-app staat live in 177 landen en de iOS-app is opnieuw gelanceerd en krijgt de meeste wijzigingen nu over the air, zonder storereview. iOS-push ging van nul geregistreerde toestellen in zes weken naar 149 zodra we de twee ontbrekende methodes in de native AppDelegate toevoegden. De eindemodus van de editie werd in één dag ontworpen, gebouwd en uitgerold.
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
De context
Een zomers muziekfestival aan de kust van Cádiz, met een seizoen van juli tot half augustus, had een officiële app voor iOS en Android, gebouwd op een no-codeplatform. Het team werkt in WordPress, waar de line-up in een eventsplugin staat, en ging ervan uit dat de app zou volgen. Dat deed hij niet.
Wat we aantroffen
Diagnose op 30 juni 2026, tien dagen voor het eerste optreden:
- De line-up stond hardcoded in de broncode en zat gecompileerd in de store-binary. Elke wijziging was een nieuwe release en een storereview.
- De Supabase-backend hoorde bij het account van de no-codeleverancier en was in de praktijk losgekoppeld van de app.
- Push had op iOS nooit gewerkt: in de native AppDelegate ontbraken de twee methodes die de device token doorgeven, dus gingen er zes seizoensweken voorbij met nul geregistreerde toestellen.
- De TypeScript-check stond op groen omdat de configuratie geen enkel bestand omvatte.
Wat we bouwden
We verhuisden de backend naar een Supabase-project dat wij zelf beheren en bouwden de contentketen opnieuw.
- Migratie in vier dagen: 31 migraties, 26 tabellen met row level security, 12 edge functions, 62 gebruikers en 62 profielen met behoud van hun IDs, 265 galerijrijen, 6 video's en 603 opslagbestanden.
- Een eigen WordPress-plugin publiceert de huidige editie via één endpoint, omdat de standaard WordPress-API de datums en tijden van de events niet teruggeeft. Een edge function synchroniseert elke 30 minuten, haalt afbeeldingen en pdf's naar onze eigen opslag, probeert het opnieuw als de firewall van de site vreemd reageert en kan zonder gevolgen twee keer draaien.
- Geautomatiseerd uitbrengen: iOS bouwt in Xcode Cloud vanaf een git-tag en dient zichzelf in via de App Store Connect API. Android bouwt, ondertekent en uploadt naar Play productie vanuit GitHub Actions.
- Over the air updates met self-hosted capgo via de OTA Hub van Polargate, met kanalen, uitrolpercentage en een minimale native versie.
- Push volledig opnieuw: APNs rechtstreeks op iOS, FCM HTTP v1 op Android, geplande campagnes met Postgres-cron, afleveringsaudit, een remote killswitch per platform en een circuit breaker die na twee mislukte pogingen stopt.
Hoe het nu draait
Het festivalteam publiceert in WordPress en binnen een half uur volgt de app, in beide stores en op het web. React, Vite, TypeScript, Tailwind en shadcn/ui aan de voorkant, Capacitor 8 voor de native schil, Supabase voor data, auth, opslag en functies, Vercel voor het web. Bij elke wijziging draaien 106 unittests en één end-to-end smoketest, en Sentry en Crashlytics melden wat er stukgaat. Polargate houdt de app draaiend op een maandelijkse onderhoudsfee: contentvragen, releases in beide stores, incidentafhandeling en het seizoenswerk van een editie afsluiten en de volgende openen.
Vragen over dit project
Hoe lang duurt het om een app van een no-codeplatform af te halen?
Kunnen jullie de app koppelen aan onze WordPress of aan ons ticketingsysteem?
Kunnen we de app bijwerken zonder elke keer een review van Apple?
Nemen jullie een app over die een ander bureau of een no-codetool heeft gebouwd?
Wat kost het om een festival-app na de lancering draaiend te houden?
Start de motor
Vertel ons in een paar korte vragen wat je bouwt. Een senior engineer antwoordt binnen twee werkdagen schriftelijk met een eerste inschatting van scope, planning en prijs.