DreamLabs
DreamLabs
[Decision guide]
For founders leaving Bubble, FlutterFlow, Softr, Adalo or an AI builder who want a foundation that grows with the product. Here's how we choose between Flutter + Firebase and React or Next.js + Supabase, with official pricing and capability facts and a decision table. DreamLabs makes the call with you in a $4,000 two-week strategy sprint, then builds; most builds take about 6 weeks after it.
Start with a strategy sprint[At a glance]
| Flutter + Firebase | React / Next.js + Supabase | |
|---|---|---|
| Best for | Mobile-first apps on iOS and Android from one codebase, especially ones that must work offline | Web-first products, pages that need search traffic, and relational data you report on |
| One codebase covers | Android, iOS, web, Windows, macOS and Linux. Flutter's docs say its web output suits app-like experiences, not text-rich pages that need search | The web, with server-rendered pages in Next.js; iOS and Android through React Native, whose docs recommend the Expo framework |
| Database | Cloud Firestore: NoSQL documents, no tables or rows. Postgres is also available through Firebase SQL Connect | Postgres: tables, joins, views and SQL |
| Offline | Built in: Firestore's Android and Apple SDKs cache data offline by default (off by default on the web) | Add a sync layer such as PowerSync, listed in Supabase's partner directory |
| Push notifications | Firebase Cloud Messaging, at no cost | No push service of its own: an Edge Function calls Firebase Cloud Messaging or Expo's push service |
| Sign-in | Free up to 50,000 monthly active users. Phone sign-in needs the Blaze plan and bills per SMS | 50,000 monthly active users free, 100,000 on Pro, then $0.00325 each. Phone sign-in needs your own SMS provider |
| Who can read what | Security Rules check every request from the app; server libraries bypass them | Row Level Security on every table the API exposes; with RLS on and no policies, the publishable key gets nothing |
| Free tier | 1 GiB of data, 50,000 reads and 20,000 writes a day. File storage and Cloud Functions need the pay-as-you-go Blaze plan | 500 MB database, 1 GB of files, two active projects; free projects pause after a week of inactivity |
| How the bill grows | Per operation: $0.03 per 100,000 reads and $0.09 per 100,000 writes past the free tier (us-central1) | Per plan and server: Pro from $25 a month including $10 of compute (a Micro server); 8 GB of disk, then $0.125 per GB; spend cap on by default |
| Leaving later | Managed export of your documents to Cloud Storage (Blaze plan), loadable into BigQuery | Standard Postgres; self-hostable with Docker, without some managed features such as branching and managed backups |
| Hiring pool (Stack Overflow 2026 survey, share of respondents) | Dart, Flutter's language: 4.9%. Cloud Firestore: 4.8% | React: 41.5%. TypeScript: 43.8%. PostgreSQL: 57.9%. Supabase: 7.7% |
| What we've shipped on it | Most of our case studies, including Grove, GlowCode, Nurture, Haikuists, KPI Dash and OOM | React for Grove's desktop experience and Nurture's admin app; we build React and Next.js on Supabase as well |
[How to choose]
Your no-code app proved the product. The stack you move to decides how fast you ship the next hundred features, who you can hire to build them and what the bill looks like at ten times the users. Our two home stacks are Flutter on Firebase and React or Next.js on Supabase, and the halves mix. Every price and capability below comes from the vendors' own docs and pricing pages, checked on October 8, 2026.
The shape of your data. Cloud Firestore is a NoSQL document database with no tables or rows, which suits data you read the way you show it: a profile, a feed, a chat. Supabase is Postgres, so joins, reporting queries and constraints come with it. The line has blurred: Firebase now offers Postgres as well, through Firebase SQL Connect, formerly Data Connect, on Cloud SQL.
The shape of the bill. Firestore bills per document operation. Past 50,000 free reads a day, the Standard edition charges $0.03 per 100,000 reads and $0.09 per 100,000 writes in us-central1 (prices vary by location), so a million reads costs 30 cents. That's cheap for screens that read what they show and expensive for screens that re-read whole collections. Supabase bills per plan and server size: Pro starts at $25 a month with $10 of compute credit, enough for a Micro server with 1 GB of RAM, and Small and Medium servers run $15 and $60 a month. The bill tracks the database server, not each request, and Pro's spend cap is on by default.
Offline. Firestore's SDKs for Android and Apple platforms keep working offline by default, caching data and syncing when the connection returns; on the web, offline persistence is off by default. On Supabase, you add a sync layer: Supabase's partner directory lists PowerSync as "a drop-in sync layer for making apps built on Supabase work offline-first." If your users work where signal drops, that difference alone can decide it.
Push notifications. Firebase Cloud Messaging is part of Firebase at no cost. Supabase has no push service of its own; its guide uses a database webhook and an Edge Function that call Firebase Cloud Messaging or Expo's push service. Same result, one more moving part.
Sign-in. Firebase Authentication is free up to 50,000 monthly active users; phone sign-in needs the pay-as-you-go Blaze plan and bills per SMS. Supabase includes 50,000 monthly active users on Free and 100,000 on Pro, then $0.00325 each, and its phone sign-in needs your own SMS provider, such as Twilio, MessageBird or Vonage.
Security. Both put your database within reach of the app, so both depend on rules you write and test. Firestore checks every request from its mobile and web libraries against Security Rules, while server libraries bypass them. Supabase asks you to enable Row Level Security on every table in an exposed schema: a table without it is readable and writable by any role with a grant on it, and with RLS on and no policies, a publishable key gets nothing. We wrote a free checklist for each.
Leaving later. Supabase is Postgres, and you can self-host it with Docker, without some managed features such as branching, managed backups and point-in-time recovery. Firestore offers a managed export of your documents to Cloud Storage on the Blaze plan, and its exports load into BigQuery.
Flutter builds for Android, iOS, web, Windows, macOS and Linux from one codebase, and it's what we build most apps in. Its own docs are candid about the web: Flutter suits app-like experiences such as single-page apps and progressive web apps, but it "is not suitable for static websites with text-rich flow-based content", and its output "doesn't align with what search engines need to properly index." When search traffic matters, landing pages, the blog and help content go in HTML, and the app stays in Flutter.
React has the larger hiring pool. In Stack Overflow's 2026 Developer Survey, 41.5% of respondents had done extensive development work in React over the past year and 43.8% in TypeScript, against 4.9% in Dart, Flutter's language. Next.js renders real HTML for search engines, and React Native, which its docs recommend starting through the Expo framework, takes the same team to iOS and Android; Expo can also statically render websites for SEO.
You don't have to pick one. Grove's mobile app is Flutter on Firebase and its desktop experience is React. Nurture's learner app is Flutter and Firebase and its admin web app is React. Haikuists goes the other way, with a Flutter mobile app for its poets and a Flutter desktop web app for its admins on one shared Firebase back end. And when native iOS is the right call, we also work in Swift.
[Four questions]
[01]
The app stores, the web or both? If search traffic matters, that part of the product needs server-rendered HTML. If the stores matter most, Flutter or React Native, from one codebase.
[02]
Documents you show as they are, such as profiles, feeds and chats, fit Firestore. Linked records you filter, join and report on fit Postgres. Your no-code app's data model already tells you which you have.
[03]
If people must keep working without signal, Firestore's built-in mobile cache saves you a sync layer. If they don't, either backend works.
[04]
Choose the stack your next hire is likely to know. React and TypeScript are the larger pool; Flutter gets one team to both app stores and the web. We settle all four in the strategy sprint.
[Where we fit]
We used to build apps in FlutterFlow, then switched to AI-accelerated development in Flutter, and we've exported most of the apps we started there. We left Webflow too, and rebuilt this site as a static site in August 2026. So we choose stacks the way we'd choose for our own products, because one of them is ours: Grove.
The stack is settled in the first two weeks. Every project starts with a two-week strategy sprint for a flat $4,000, refunded in full if we don't move forward together: we map your current app into a features table, wireframes and the scope of your first release, and choose the data architecture with you. Your build price is set and approved at the end of the sprint, and most builds take about 6 weeks after it. You own the code, the cloud accounts and the store listings.
[Platform guides]
[Exports and stacks]
Built it with Lovable, Bolt, v0, or Replit instead? See AI prototype to production →
[FAQs]
Neither in general; they suit different apps. Firebase's Firestore is a NoSQL document database that works offline on Android and iOS by default and comes with free push notifications through Firebase Cloud Messaging, which suits mobile-first apps. Supabase is Postgres, with joins, SQL and Row Level Security, which suits web-first products and data you report on, and you can self-host it. Firebase bills per read and write; Supabase bills per plan and server size, from $25 a month on Pro.
Bubble can't export your app as code, so the logic is rebuilt from the running app while your data and design come across. Depending on the app, we move the web app to React and Next.js on Firebase or Supabase, or to a TypeScript API over PostgreSQL. If the product also needs iOS and Android apps, Flutter on Firebase covers both stores and the web from one codebase. The choice depends on where your users are, the shape of your data and who will maintain it.
Both ship real iOS and Android apps from one codebase. Flutter also builds for the web and desktop, and it's what we build most apps in; React Native, which its docs recommend starting through Expo, lets a React team reuse its skills, and React has the larger hiring pool (41.5% of respondents to Stack Overflow's 2026 survey had worked extensively in React, against 4.9% in Dart). If your team already knows one, use it.
It depends on how your app reads data. Firestore charges per operation: past 50,000 free reads a day, $0.03 per 100,000 reads and $0.09 per 100,000 writes in us-central1, so a million reads costs 30 cents. Supabase charges per plan and server: Pro starts at $25 a month with $10 of compute credit for a Micro server, and larger servers cost more. Apps that read only what each screen shows stay cheap on Firestore; apps that re-read large collections may be cheaper on a fixed server.
Not out of the box the way Firestore does on mobile. Supabase's partner directory lists PowerSync as a drop-in sync layer for making apps built on Supabase work offline-first. Firestore's Android and Apple SDKs cache data and keep working offline by default.
Usually, yes. FlutterFlow apps run on a Firebase or Supabase project you connect, and FlutterFlow includes code download from its Basic plan. A move to a production Flutter codebase can keep that backend, so users keep their accounts and simply get an app update. We used to build in FlutterFlow ourselves and have exported most of the apps we started there.
For app-like experiences, yes: Flutter's docs name single-page apps, progressive web apps and existing Flutter mobile apps as good fits. For marketing pages, a blog or help content that needs search traffic, no: Flutter's docs say it isn't suitable for text-rich static sites and recommend HTML, or the Dart-based Jaspr package, for that content.
Every DreamLabs project starts with a two-week strategy sprint for a flat $4,000, refunded in full if we don't move forward together. The sprint maps your current app into a features table and the scope of the first release, and settles the stack. Your build price is set and approved at the end of the sprint, and most builds take about 6 weeks after it.
[Interested?]
