1. Building Before Defining the Data Model

The most common mistake: starting in FlutterFlow before modelling the data in Supabase. You build 8 screens, then realise your data structure doesn't support the features you need. Every screen has to be rebuilt.

The fix: spend day one in Supabase's table editor, not in FlutterFlow. Define every table, every column, every foreign key relationship. Ask: "Can I query all the data I need for each screen from this schema?" If yes, start building. If not, fix the schema first.

Data modelling takes 2–4 hours. Rebuilding screens from a wrong schema takes days.

2. Skipping Row-Level Security

Building a multi-user app without Row-Level Security (RLS) means every user can potentially access every other user's data — a serious security and compliance failure.

The fix: enable RLS on every Supabase table from day one. Write the policies:
- Users table: `using (auth.uid() = id)`
- Items table: `using (auth.uid() = user_id)` or `using (org_id IN (SELECT org_id FROM memberships WHERE user_id = auth.uid()))`

Test by creating two test users and verifying that user A cannot see user B's data. This test takes 10 minutes and should be done before any other testing.

3. Treating the FlutterFlow Preview as Testing

FlutterFlow's browser preview is convenient but it doesn't represent real device behaviour. We've seen apps that work perfectly in preview but crash on iOS, have broken gestures on Android, or display incorrectly on smaller screens.

The fix: test on physical devices weekly throughout development, not just before launch. Use FlutterFlow's "Test Mode" to get a QR code that installs the app on your device. Test on at least one iPhone and one Android device, with different screen sizes.

4. Building Everything Before Testing With Users

Founders often build a complete app — 15 screens, 8 features — before showing it to a single real user. Then they learn that users want something different and have to redesign half the app.

The fix: build the core workflow (3–4 screens) in week 2 and put it in front of 5 real users. What do they try to do that doesn't exist? What do they find confusing? What do they ignore? This feedback shapes weeks 3–6 and saves significant rework.

5. Ignoring App Store Guidelines During Development

App Store rejection after 8 weeks of development is demoralising and expensive. Common rejection reasons:

- No privacy policy linked in the app and the App Store listing - Missing "Sign in with Apple" option when the app offers Google or Facebook login (Apple requires it) - App that's essentially a website wrapper with no native functionality - Missing data deletion feature (required since 2024) - Payments made outside Apple's in-app purchase system for digital goods

The fix: review Apple's App Store Review Guidelines at the start of the project. Build the privacy policy, account deletion flow, and Sign in with Apple from day one.

6. Not Planning for Offline Behaviour

Mobile users lose connectivity — on the subway, in buildings, travelling. An app that shows a blank screen when offline loses trust.

FlutterFlow with Supabase doesn't support offline-first out of the box. The fix: implement graceful degradation. Cache the last successful data fetch in SharedPreferences. Show a "You're offline — showing cached data" banner. Disable write actions with a clear message. Users understand offline limitations — they don't understand a blank app.

7. Underestimating Post-Launch Maintenance

No-code apps aren't zero-maintenance. FlutterFlow releases updates that occasionally break existing functionality. Supabase deprecates APIs. Apple requires updates to support new iOS versions.

Budget 15–20% of development cost per year for maintenance. This covers: FlutterFlow version upgrades, dependency updates, iOS/Android compatibility fixes, and the inevitable "can we add this small feature" requests from users.

Contracts with clients should include a clear maintenance clause. Projects without it become disputes when the first iOS update breaks the app.