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).

Djupdykning i misstag: Fel datamodell

Av alla misstag vi ser orsakar en bristfällig datamodell det dyraste omarbetet. Det vanligaste datamodell-misstaget är att bygga en platt struktur när produkten kräver relationsdata. Ett exempel: en app för att hantera kundprojekt lagrar all projektdata i en enda tabell med kolumner för kundnamn, projektnamn och status. Detta fungerar för en kund per projekt men fallerar när en kund har flera kontaktpersoner, ett projekt har flera milstolpar, eller en milstolpe har flera uppgifter. Att lägga till dessa funktioner kräver att hela schemat omstruktureras och att varje skärm kopplas om.

Det näst vanligaste misstaget är att underdimensionera relationen mellan användare och organisation. En multi-tenant-app där användare tillhör organisationer behöver en users-tabell, en organisations-tabell och en memberships-korstabell (junction table). Att försöka modellera detta som en enda users-tabell med en org_id-kolumn går sönder så fort en användare behöver tillhöra flera organisationer eller en organisation har olika behörighetsnivåer per medlem.

På App Studio börjar varje projekt med en datamodelleringsworkshop innan någon skärm designas. Vi ritar entitetsrelationsdiagrammet, definierar varje foreign key och validerar att vi kan skriva SQL-frågan för varje skärms datakrav. Denna investering på 4-6 timmar i början har räddat varje kund från flerdagars ombyggnader senare.

Djupdykning i misstag: Att ignorera konsekvenserna av att hoppa över Row-Level Security

Att hoppa över RLS är inte bara en säkerhetsrisk, det skapar en underhållsbörda som växer över tid. Utan RLS måste varje fråga i din app inkludera manuell användarfiltrering: where user_id = currentUserId. Varje utvecklare som rör koden måste komma ihåg att lägga till detta filter. När någon glömmer, och någon glömmer alltid, sker ett dataläckage tyst, utan något felmeddelande som varnar dig.

Med RLS aktiverat från dag ett upprätthåller databasen dataisolering automatiskt. En fråga utan användarfilter returnerar fortfarande bara de rader den autentiserade användaren har rätt att se, eftersom RLS-policyn tillämpas på databaslagret innan resultaten returneras. Det betyder att även en felkonfigurerad frontend-fråga inte kan exponera en annan användares data.

För europeiska appar kräver GDPR-efterlevnad att personuppgifter isoleras mellan användare. RLS är en av de tekniska kontrollerna revisorer letar efter vid bedömning av GDPR-efterlevnad. Att bygga utan det skapar en efterlevnadslucka som är dyr att stänga i efterhand, särskilt eftersom det att lägga till RLS efter att appen är byggd kräver en granskning av varje befintlig fråga för att säkerställa att ingen förlitade sig på frånvaron av radnivåfiltrering.

Djupdykning i misstag: Att överkonstruera den första versionen

No-code-verktyg möjliggör snabb iteration, men grundare använder dem ibland för att bygga den fullt utrustade visionen istället för den minimalt gångbara produkten. Vi har sett första versioner med komplexa rollhierarkier, stöd för flera valutor, API-integrationer för tjänster som ännu inte har några användare, och offline-synkronisering för en app som aldrig haft en användare lämna kontoret. Allt detta byggdes innan någon hade registrerat sig.

Överkonstruktionsmisstaget är särskilt smärtsamt i no-code eftersom komplexitet i FlutterFlow förstärks. Att lägga till en tredje användarrolltyp innebär att granska varje skärm för behörighetslogik. Att lägga till stöd för flera valutor innebär att gå igenom varje datavisning, inmatning och beräkning på nytt. Funktioner som läggs till spekulativt före validering behöver ofta tas bort eller omdesignas när riktiga användare ger feedback.

Disciplinen som krävs för en MVP är att skära bort varje funktion som inte krävs för att kärnarbetsflödet ska fungera. På App Studio använder vi ett "launch sprint"-koncept: den sista sprinten innan inlämning innehåller endast buggfixar och App Store-efterlevnadsarbete, inga nya funktioner. Varje funktion som missar launch-sprinten hamnar på v1.1-backloggen. Detta säkerställer att lanseringar sker enligt tidsplan och att team inte lägger fyra extra veckor på att lägga till funktioner i en app som ännu har noll användare.

Djupdykning i misstag: Att välja fel monetiseringsmodell

Val av monetiseringsmodell för mobilappar har direkta tekniska konsekvenser som ofta upptäcks för sent. De två dyraste sena upptäckterna: att välja köp i appen efter att ha byggt ett prenumerationsflöde med Stripes webb-SDK, och att välja en gratis-med-annonser-modell utan att räkna med SDK-vikten och integritetskonsekvenserna av annonsnätverk.

Apple kräver köp i appen för digitala varor som säljs i iOS-appar. Om du planerar att sälja prenumerationer, förbrukningsbara krediter eller premiumfunktioner måste du använda Apples StoreKit-API:er. Du kan inte länka till en webbetalningssida för dessa köp (Apple förbjuder det uttryckligen). FlutterFlow stöder köp i appen via RevenueCat-plugin, men integrationen ökar komplexiteten och kräver noggrann hantering av kvittovalidering via en server-side Edge Function.

För B2B-appar där köparen är ett företag, inte en privatperson, är Apples IAP-regler mer flexibla. B2B-appar kan fakturera via externa betalningssystem eftersom produkten säljs till ett företag, inte en konsument. Om din app har en tydlig B2B-modell, där företag betalar månadsvis via faktura eller Stripe, kan du undvika StoreKit helt. Att definiera detta i början av projektet förhindrar en smärtsam kursändring sex veckor in i utvecklingen när någon frågar "hur betalar användarna?"

Hur App Studio undviker dessa misstag

På App Studio är vår projektprocess utformad för att fånga dessa felmönster innan de kostar tid eller pengar. Varje uppdrag börjar med en tvådagars upptäcktsfas: datamodellering, kartläggning av användarresor, granskning av App Store-efterlevnad och definition av monetiseringsarkitektur. Ingenting byggs förrän dataschemat är validerat och arkitekturbesluten är dokumenterade.

Vi genomför en säkerhetsgranskning i slutet av varje sprint. Detta inkluderar att verifiera att RLS-policyer är aktiva på varje ny tabell, testa med två isolerade testkonton för att bekräfta dataseparation, och kontrollera att inga API-nycklar eller hemligheter är hårdkodade i frontend-koden.

Användartestning är schemalagd, inte valfri. Efter att kärnarbetsflödet är byggt (vanligtvis vecka 2 eller 3) schemalägger vi 5 användartester innan utvecklingen fortsätter. Resultaten formar direkt nästa sprints prioriteringar. Över 50+ appprojekt har denna process eliminerat felmönstret "byggde fel sak" som gör att de flesta no-code-projekt misslyckas. Processens disciplin överväger hastighetsfördelen av att hoppa över den.