1. Bygga utan att definiera datamodellen

Det vanligaste misstaget: börja i FlutterFlow innan du modellerat data i Supabase. Du bygger 8 skärmar, sedan inser du att din datastruktur inte stöder de funktioner du behöver. Varje skärm måste byggas om.

Lösningen: tillbringa dag ett i Supabase tabellredigerare, inte i FlutterFlow. Definiera varje tabell, varje kolumn, varje foreign key-relation. Fråga: "Kan jag fråga all data jag behöver för varje skärm från detta schema?" Om ja, börja bygga. Om nej, fixa schemat först.

Datamodellering tar 2–4 timmar. Att bygga om skärmar från ett felaktigt schema tar dagar. För svenska SaaS-produkter riktade mot B2B-kunder är korrekt multi-tenant-schema (med org_id på varje tabell) inte valfritt — det måste vara rätt från start.

2. Hoppa över Row-Level Security

Att bygga en flerbrukare-app utan Row-Level Security (RLS) innebär att varje användare potentiellt kan komma åt varje annan användares data — ett allvarligt säkerhets- och efterlevnadsfel.

Lösningen: aktivera RLS på varje Supabase-tabell från dag ett. Skriv policys: - Users-tabell: `using (auth.uid() = id)` - Items-tabell: `using (auth.uid() = user_id)` eller `using (org_id IN (SELECT org_id FROM memberships WHERE user_id = auth.uid()))`

Testa genom att skapa två testanvändare och verifiera att användare A inte kan se användare B:s data. Detta test tar 10 minuter och bör göras innan annan testning.

Under GDPR är dataläckor inte bara skadliga för varumärket — de kan resultera i böter upp till 4% av global omsättning. RLS är ditt tekniska skydd.

3. Behandla FlutterFlow-förhandsvisningen som testning

FlutterFlows webbläsarförhandsvisning är bekväm men den representerar inte verkligt enhetsbeteende. Vi har sett appar som fungerar perfekt i förhandsvisning men kraschar på iOS, har trasiga gester på Android eller visas felaktigt på mindre skärmar.

Lösningen: testa på fysiska enheter varje vecka under utveckling, inte bara inför lansering. Använd FlutterFlows "Test Mode" för att få en QR-kod som installerar appen på din enhet. Testa på minst en iPhone och en Android-enhet med olika skärmstorlekar.

För svenska appar: testa specifikt på iPhone SE (liten skärm, populär bland äldre användare) och Samsung Galaxy S-serien. UI som ser bra ut på iPhone 15 Pro Max kan vara trasigt på iPhone SE.

4. Bygga allt innan testning med användare

Grundare bygger ofta en komplett app — 15 skärmar, 8 funktioner — innan de visar den för en enda riktig användare. Sedan lär de sig att användare vill ha något annorlunda och måste omdesigna halva appen.

Lösningen: bygg kärnarbetsflödet (3–4 skärmar) under vecka 2 och sätt det framför 5 riktiga användare. Vad försöker de göra som inte finns? Vad tycker de är förvirrande? Vad ignorerar de? Denna feedback formar vecka 3–6 och sparar betydande omarbete.

För svenska B2B-appar: de 5 tidiga användarna bör vara yrkesverksamma i din målgrupp — inte vänner och familj. Boka 30-minuterssessioner och observera utan att vägleda. Du lär dig mer av 5 observerade användarsessioner än av 5 veckors intern diskussion.

5. Ignorera App Store-riktlinjer under utveckling

App Store-avvisning efter 8 veckors utveckling är demorierande och dyrt. Vanliga avvisningsskäl:

- Ingen integritetspolicy länkad i appen och App Store-listan - Saknar "Sign in with Apple"-alternativ när appen erbjuder Google- eller Facebook-inloggning (Apple kräver det) - App som i grunden är en webbplatswrapper utan native-funktionalitet - Saknar datafunktion för radering (krävs sedan 2024) - Betalningar gjorda utanför Apples köp i appen-system för digitala varor

Lösningen: granska Apples App Store-granskningsriktlinjer i början av projektet. Bygg integritetspolicyn, kontoraderings-flödet och Sign in with Apple från dag ett. För svenska appar: integritetspolicyn måste uppfylla GDPR och bör finnas på svenska.

6. Planera inte för offline-beteende

Mobilanvändare tappar anslutning — i tunnelbanan, i byggnader, när de reser. En app som visar en tom skärm offline förlorar förtroende.

FlutterFlow med Supabase stöder inte offline-first direkt. Lösningen: implementera graciös degradering. Cachelagra den senaste lyckade datahämtningen i SharedPreferences. Visa en "Du är offline — visar cachad data"-banner. Inaktivera skriv-åtgärder med ett tydligt meddelande. Användare förstår offline-begränsningar — de förstår inte en tom app.

För svenska affärsappar som används av fältarbetare (byggnad, logistik, vård) är offline-graciositet ett absolut krav, inte ett bra-att-ha.

7. Underskatta underhåll efter lansering

No-code-appar är inte noll-underhåll. FlutterFlow släpper uppdateringar som ibland bryter befintlig funktionalitet. Supabase deprecierar API:er. Apple kräver uppdateringar för att stödja nya iOS-versioner.

Budgetera 15–20% av utvecklingskostnaden per år för underhåll. Det täcker: FlutterFlow-versionsuppgraderingar, beroenduppdateringar, iOS/Android-kompatibilitetskorrigeringar och de oundvikliga "kan vi lägga till den här lilla funktionen"-förfrågningarna från användare.

Kontrakt med kunder bör inkludera en tydlig underhållsklausul. Projekt utan den leder till tvister när den första iOS-uppdateringen bryter appen. I Sverige: inkludera explicit i kontraktet vad som täcks (kritiska buggar, iOS/Android-kompatibilitet) och vad som faktureras separat (nya funktioner, omdesign).