I Built and Shipped a Flutter Community App in 7 Days — Here's Exactly How

aarviapps — Mon, 22 Jun 2026 10:57:36 +0000

Seven days. One developer. Zero shortcuts.

FeastFriends is a community app where users answer one question per day and discover how others think about the same topic. It's live on the Play Store. I built it alone in a week.

This is the honest breakdown of how.

The Idea

Social apps are exhausting. Infinite scroll, algorithmic pressure, the anxiety of posting. I wanted the opposite — something that gives you exactly one thing per day and nothing more.

One question. You answer it. Then — and only then — you see how everyone else answered.

That "reveal after answer" mechanic was the entire product. Everything else was secondary.

Why Flutter + Supabase

I've shipped apps in native Android (Kotlin), Flutter, and React Native. For a 7-day build, the stack choice is everything.

Flutter because hot reload means UI changes take seconds not minutes, single codebase covers Android and iOS, and the widget library meant I never had to build basic components from scratch.

Supabase because it gave me auth (email + Google), a real PostgreSQL database, real-time subscriptions for the live feed, row-level security for data privacy, and Edge Functions for the daily scheduler — all in one. It probably saved 3–4 days compared to a custom backend.

Day-by-Day Breakdown

Day 1 — Architecture only, no UI

I made a rule: no UI on day one. Just the data model.

I mapped out five tables — questions, answers, options, votes, and users — and defined every relationship before writing a single widget. Getting this right on day one meant zero schema changes for the rest of the week. Worth every hour.

Day 2 — Auth + Navigation shell

Supabase auth took about 2 hours. Email and Google sign-in, session persistence, redirect handling. Then I built the navigation shell — a bottom nav with three tabs (Today, Feed, Profile) with placeholder screens everywhere. The app ran end-to-end with no real features. That skeleton matters more than people think.

Day 3 — The core mechanic

The "answer before reveal" flow has four states: user hasn't answered yet, user is answering, user just submitted, user already answered today. Each state needs a different screen and different navigation logic.

I rewrote the navigation logic twice. Get it wrong and the whole product breaks — users end up on the wrong screen or can peek at others' answers before submitting. This single day was the most important of the build.

Day 4 — Community feed + voting

Real-time feed of today's answers using Supabase's live subscriptions. New answers appear without refreshing. Voting was a simple toggle — write or delete a row in the votes table depending on current state.

The hardest part here wasn't technical. It was deciding how much of others' answers to show and in what order. I kept it chronological. No algorithm. Intentional.

Day 5 — Daily question engine

A Supabase Edge Function runs every night at midnight UTC. It activates the next scheduled question and sends a push notification to all users via FCM.

Setting up FCM with Flutter's firebase_messaging package took about 3 hours including Firebase console configuration — longer than I expected. This is the one part I'd research before the build next time.

Day 6 — Polish

Skeleton loading screens instead of spinners. Empty states for every edge case. Error handling for network failures and auth errors. Tested on a physical Android device and iOS simulator.

The UI felt rough on day 5. Day 6 made it feel like a real product.

Day 7 — Play Store submission

Generated the release AAB, created the Play Store listing (screenshots, description, content rating questionnaire), checked the privacy policy was live on my website, and submitted. Google approved it in about 3 days.

What I Cut

Features I planned but dropped to ship on time:

User profiles — nice to have, not core to the daily question loop
Comment threads — too complex, opens moderation problems
User-submitted questions — Phase 2
Share to social — added after launch

Every cut feature is a future update. Shipping beats perfect.

What I'd Do Differently

Analytics from day one. I added tracking after launch and had zero data on the first week of real usage. Blind spots everywhere.

Onboarding flow. The "answer before reveal" mechanic confused new users who didn't read the description. A 3-screen onboarding walkthrough should have been day one, not an afterthought.

Play Store screenshots. I spent maybe 30 minutes on them. They're the first thing a potential user sees. Better screenshots would have driven more installs from day one.

The Result

FeastFriends is live on the Play Store. Built alone in 7 days.

Is it perfect? No. Does it work, solve the problem, and have real users? Yes.

That's what shipping means.

About Me

I'm Lalit, a Flutter developer based in Ahmedabad, India. I build mobile apps for startups and businesses through AarviApps.

If you're building something and need a developer who ships fast without cutting corners — let's talk.

👉 aarviapps.com
📧 lalit@aarviapps.com

Drop any Flutter or Supabase questions in the comments — happy to help.

DEV Community: aarviapps

I Built and Shipped a Flutter Community App in 7 Days — Here's Exactly How