I've Built 30+ Startup Apps with Flutter — Here's Why I Keep Choosing It in 2026

I started building Flutter apps for startup clients in 2021. Four years and roughly 30 projects later, I have a pattern I follow for every new startup that walks through the door. It doesn't involve debating frameworks for a week. It doesn't involve building a custom backend from scratch. And it definitely doesn't involve hiring separate iOS and Android teams on a seed-stage budget.

The pattern is straightforward: Flutter for the client, Firebase or Supabase for the backend, Riverpod for state, and a relentless focus on getting to the app store before the runway gets too short. This post is everything I've learned doing this — the costs, the architecture, the mistakes, and the honest moments where I told a client to use something other than Flutter.

Why I Keep Picking Flutter for Startup Clients

A startup founder doesn't care about rendering engines or widget trees. They care about three things: how fast can you ship it, how much will it cost, and will it work on both platforms. Flutter answers all three better than any alternative I've used. One codebase compiles to iOS, Android, web, macOS, Windows, and Linux. I typically share 85-95% of code between iOS and Android, with the remaining 5-15% being platform-specific quirks like notification permissions or deep linking setup.

The math is simple. Hiring a Swift developer and a Kotlin developer to build the same app separately costs roughly 2x and takes 1.5-2x as long because of parallel workstreams, communication overhead, and the inevitable "why does this screen look different on Android?" conversations. With Flutter, one developer (or a small team) builds once and both platforms ship together. For a startup burning through seed money, that difference is the difference between launching with 6 months of runway left versus launching with 2. I wrote about the performance side of Flutter separately — this post focuses on the business and architecture decisions that matter when you're building against a deadline.

The Real Cost Breakdown — Numbers from My Projects

I'll share actual numbers instead of generic "40-60% savings" claims. These are from real projects I've done for startup clients, with details anonymized:

The savings come from three places: shared UI code (obvious), shared business logic (less obvious — Dart classes for models, validation, and API parsing work identically on both platforms), and shared testing (one test suite covers both platforms). The testing savings alone are worth 10-15% of the budget because you're not writing the same tests twice. If you want the technical details on how I structure testing for Flutter apps, I covered that separately.

My Exact Startup Stack in 2026

This is the stack I start every new startup project with. I've refined it over 30+ projects and it balances speed, cost, and scalability:

# pubspec.yaml — My standard startup MVP dependencies
name: startup_mvp
description: A production Flutter startup app

environment:
  sdk: '>=3.5.0 <4.0.0'

dependencies:
  flutter:
    sdk: flutter

  # State Management
  flutter_riverpod: ^3.0.0
  riverpod_annotation: ^3.0.0

  # Backend
  firebase_core: ^3.8.0
  firebase_auth: ^5.3.0
  cloud_firestore: ^5.5.0
  firebase_storage: ^12.3.0
  firebase_messaging: ^15.1.0

  # Navigation
  go_router: ^14.6.0

  # Networking
  dio: ^5.7.0

  # Local Storage
  shared_preferences: ^2.3.0
  hive_flutter: ^1.1.0

  # UI
  flutter_screenutil: ^5.9.0
  cached_network_image: ^3.4.0
  shimmer: ^3.0.0

  # Payments (if needed)
  flutter_stripe: ^11.2.0

  # Analytics
  firebase_analytics: ^11.3.0

dev_dependencies:
  flutter_test:
    sdk: flutter
  riverpod_generator: ^3.0.0
  build_runner: ^2.4.0
  flutter_lints: ^5.0.0
  mocktail: ^1.0.0

Every package here earns its place. I used to add packages speculatively ("we might need this later") — that's a mistake I'll talk about in the mistakes section. The rule now is: if a feature isn't in the current sprint, the package isn't in pubspec.yaml. For more on picking the right packages, check my top Flutter packages guide.

Project Structure I Use for Every MVP

After trying repository pattern, clean architecture, and every folder structure Medium article suggests, I settled on feature-first organization. It's boring. It works.

lib/
├── app/
│   ├── app.dart                  # MaterialApp + GoRouter setup
│   ├── theme.dart                # App theme and colors
│   └── routes.dart               # Route definitions
├── core/
│   ├── constants/                # API URLs, keys, config
│   ├── extensions/               # Dart extensions
│   ├── services/                 # Analytics, crash reporting
│   └── utils/                    # Formatters, validators
├── features/
│   ├── auth/
│   │   ├── data/                 # Repository, data sources
│   │   ├── domain/               # Models, entities
│   │   ├── presentation/         # Screens, widgets
│   │   └── providers/            # Riverpod providers
│   ├── home/
│   │   ├── data/
│   │   ├── domain/
│   │   ├── presentation/
│   │   └── providers/
│   └── profile/
│       ├── data/
│       ├── domain/
│       ├── presentation/
│       └── providers/
├── shared/
│   ├── widgets/                  # Reusable UI components
│   ├── models/                   # Shared data models
│   └── providers/                # App-wide providers
└── main.dart

The key insight: every feature is self-contained. When a feature gets cut (startups pivot constantly), I delete one folder and its tests. No untangling shared state, no orphaned imports across the codebase. For more on structuring Flutter projects properly, I wrote about clean architecture patterns that scale from MVP to production.

Firebase vs Supabase — The BaaS Decision

This is the first architecture decision I make with every startup client. Both work. The choice depends on three factors:

Choose Firebase when: you want to ship the fastest possible MVP, your data model is document-oriented (user profiles, orders, content), you need real-time sync out of the box, and you want Cloud Functions for server-side logic without managing servers. Firebase's free tier covers most startups through their first 10K-50K users.

Choose Supabase when: your data is relational (joins matter), your team knows SQL, you want to avoid vendor lock-in, or you need row-level security policies for complex authorization. Supabase's free tier is generous and the Supabase vs Firebase comparison I wrote covers the specifics.

// Firebase setup — typically done in main.dart
Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );
  runApp(const ProviderScope(child: MyApp()));
}

// Supabase setup — same pattern
Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Supabase.initialize(
    url: const String.fromEnvironment('SUPABASE_URL'),
    anonKey: const String.fromEnvironment('SUPABASE_ANON_KEY'),
  );
  runApp(const ProviderScope(child: MyApp()));
}

For startups that aren't sure, I default to Firebase. The migration path from Firebase to a custom backend (or to Supabase) is well-documented and I've done it three times. Starting with Firebase doesn't lock you in — it gives you speed now with optionality later.

State Management for MVPs — Stop Overthinking It

I've watched startup teams spend two weeks debating state management before writing a single feature. That's two weeks of runway gone. Here's my decision tree and it takes 30 seconds:

// Simple feature with local UI state? Use setState.
class QuantitySelector extends StatefulWidget {
  const QuantitySelector({super.key, required this.onChanged});
  final ValueChanged<int> onChanged;

  @override
  State<QuantitySelector> createState() => _QuantitySelectorState();
}

class _QuantitySelectorState extends State<QuantitySelector> {
  int _quantity = 1;

  @override
  Widget build(BuildContext context) {
    return Row(
      children: [
        IconButton(
          onPressed: () {
            setState(() { _quantity = (_quantity - 1).clamp(1, 99); });
            widget.onChanged(_quantity);
          },
          icon: const Icon(Icons.remove),
        ),
        Text('$_quantity'),
        IconButton(
          onPressed: () {
            setState(() { _quantity = (_quantity + 1).clamp(1, 99); });
            widget.onChanged(_quantity);
          },
          icon: const Icon(Icons.add),
        ),
      ],
    );
  }
}

// Feature with shared state, async data, or DI? Use Riverpod.
@riverpod
class CartNotifier extends _$CartNotifier {
  @override
  List<CartItem> build() => [];

  void addItem(Product product) {
    final existing = state.indexWhere((item) => item.productId == product.id);
    if (existing != -1) {
      final updated = [...state];
      updated[existing] = updated[existing].copyWith(
        quantity: updated[existing].quantity + 1,
      );
      state = updated;
    } else {
      state = [...state, CartItem.fromProduct(product)];
    }
  }

  void removeItem(String productId) {
    state = state.where((item) => item.productId != productId).toList();
  }
}

@riverpod
double cartTotal(Ref ref) {
  final items = ref.watch(cartNotifierProvider);
  return items.fold(0.0, (sum, item) => sum + item.price * item.quantity);
}

That's it. setState for local widget state, Riverpod for shared or async state. If a feature gets complex enough to need event-sourced state transitions (rare in MVPs), I'll reach for Bloc for that specific feature. But in 30+ startup projects, maybe 3 features across all of them actually needed Bloc's formality. The rest were fine with Riverpod. For teams that want even less boilerplate, signals are worth considering for UI-level reactivity.

Authentication in 20 Minutes

Every startup app needs auth. Here's the pattern I've refined to get email/password + Google sign-in working in 20 minutes with Firebase Auth:

// providers/auth_provider.dart
@riverpod
Stream<User?> authState(Ref ref) {
  return FirebaseAuth.instance.authStateChanges();
}

@riverpod
class AuthNotifier extends _$AuthNotifier {
  @override
  FutureOr<void> build() {}

  Future<void> signInWithEmail(String email, String password) async {
    state = const AsyncLoading();
    state = await AsyncValue.guard(() async {
      await FirebaseAuth.instance.signInWithEmailAndPassword(
        email: email.trim(),
        password: password,
      );
    });
  }

  Future<void> signInWithGoogle() async {
    state = const AsyncLoading();
    state = await AsyncValue.guard(() async {
      final googleUser = await GoogleSignIn().signIn();
      if (googleUser == null) throw Exception('Google sign-in cancelled');
      final auth = await googleUser.authentication;
      final credential = GoogleAuthProvider.credential(
        accessToken: auth.accessToken,
        idToken: auth.idToken,
      );
      await FirebaseAuth.instance.signInWithCredential(credential);
    });
  }

  Future<void> signOut() async {
    await FirebaseAuth.instance.signOut();
    await GoogleSignIn().signOut();
  }
}

// routes.dart — GoRouter with auth redirect
final routerProvider = Provider<GoRouter>((ref) {
  final authState = ref.watch(authStateProvider);

  return GoRouter(
    initialLocation: '/',
    redirect: (context, state) {
      final isLoggedIn = authState.valueOrNull != null;
      final isAuthRoute = state.matchedLocation.startsWith('/auth');

      if (!isLoggedIn && !isAuthRoute) return '/auth/login';
      if (isLoggedIn && isAuthRoute) return '/';
      return null;
    },
    routes: [
      GoRoute(path: '/', builder: (_, __) => const HomeScreen()),
      GoRoute(path: '/auth/login', builder: (_, __) => const LoginScreen()),
      GoRoute(path: '/auth/register', builder: (_, __) => const RegisterScreen()),
    ],
  );
});

This pattern handles: email/password login, Google sign-in, automatic redirects when auth state changes, loading states, and error handling. I've used it in every startup project since early 2024. The auth provider watches Firebase's auth state stream, GoRouter redirects based on that state, and the UI just works. For apps that need more advanced auth (biometrics, MFA), I covered that in my app security guide.

Flutter vs React Native in 2026 — The Honest Comparison

This is the question every startup founder asks. My answer depends on the team, not the framework:

I pick Flutter because the developer experience is faster for the kinds of apps startups need: data-driven UIs, form-heavy workflows, real-time updates, and custom-designed screens. React Native wins when the startup already has a React web team or when the app is primarily a wrapper around web views. Both ship production apps. The "which is better" debate is mostly noise — what matters is which one your team can ship faster with.

When to Go Native Instead

I've talked three clients out of Flutter and into native development. Here's when I do that:

The app IS the platform integration. One client wanted an app that was 80% ARKit features with custom Metal shaders. Flutter's platform channels would have been a constant bottleneck. They went with Swift and the project was smoother for it.

The startup only targets one platform. A client building exclusively for iPad (enterprise field service tool) didn't need cross-platform at all. Native SwiftUI gave them better iPad multitasking, better Apple Pencil support, and a smaller app size. Flutter's strength is multi-platform — if you only need one, native is often simpler.

Performance requirements are extreme. A real-time audio processing app needed sub-10ms latency. Flutter's rendering pipeline adds a frame of latency that didn't matter for any other project I've done, but for real-time audio it was a deal-breaker. They went with Kotlin/Swift and platform audio APIs directly.

Hot Reload and Why Iteration Speed Matters More Than Performance

Performance benchmarks on Flutter vs native are within 5-10% for virtually any app that isn't a game or real-time audio processor. But iteration speed is where Flutter creates a 2-3x multiplier that no benchmark captures. Hot reload — seeing code changes in under a second without losing app state — means I can try 20 UI variations in the time it takes to try 5 on native.

For startups, this matters more than any performance metric. The MVP you ship is never the final version. You iterate based on user feedback, pivot features, redesign flows. Every iteration cycle that takes minutes instead of seconds costs time and focus. I've tracked this roughly: on a typical sprint day, I rebuild the app 80-150 times with hot reload. On native, full rebuilds after non-trivial changes take 15-45 seconds each. That adds up to 20-60 minutes of waiting per day, every day, for the entire development cycle.

// Hot reload preserves state — change this text color
// and see it instantly without losing your scroll position,
// form data, or navigation state
class ProductCard extends StatelessWidget {
  const ProductCard({super.key, required this.product});
  final Product product;

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Column(
        children: [
          CachedNetworkImage(
            imageUrl: product.imageUrl,
            placeholder: (_, __) => const Shimmer(width: double.infinity, height: 200),
          ),
          Padding(
            padding: const EdgeInsets.all(12),
            child: Column(
              crossAxisAlignment: CrossAxisAlignment.start,
              children: [
                Text(
                  product.name,
                  style: Theme.of(context).textTheme.titleMedium,
                  // Change this style ↑ and hot reload — instant feedback
                ),
                const SizedBox(height: 4),
                Text(
                  '\$${product.price.toStringAsFixed(2)}',
                  style: Theme.of(context).textTheme.bodyLarge?.copyWith(
                    color: Theme.of(context).colorScheme.primary,
                    fontWeight: FontWeight.bold,
                  ),
                ),
              ],
            ),
          ),
        ],
      ),
    );
  }
}

Shipping Web and Mobile from One Codebase

Several startup clients need a mobile app for customers and a web dashboard for admins. Flutter can build both from one codebase, but the approach matters:

// Responsive layout that works on mobile and web
class DashboardScreen extends StatelessWidget {
  const DashboardScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return LayoutBuilder(
      builder: (context, constraints) {
        if (constraints.maxWidth > 900) {
          // Web/desktop layout — sidebar + content
          return Row(
            children: [
              const SizedBox(width: 280, child: SideNavigation()),
              Expanded(child: _buildContent(context)),
            ],
          );
        }
        // Mobile layout — bottom nav + content
        return Scaffold(
          body: _buildContent(context),
          bottomNavigationBar: const MobileNavigation(),
        );
      },
    );
  }

  Widget _buildContent(BuildContext context) {
    return const SingleChildScrollView(
      padding: EdgeInsets.all(16),
      child: Column(
        children: [
          StatsGrid(),
          SizedBox(height: 16),
          RecentOrdersTable(),
          SizedBox(height: 16),
          RevenueChart(),
        ],
      ),
    );
  }
}

Flutter web works well for internal dashboards and admin tools. I don't recommend it for public-facing marketing sites or content-heavy pages because the initial load bundle is larger than equivalent HTML/CSS and SEO is limited. But for authenticated dashboards where the user lands on a login screen first and then interacts with data-heavy views, Flutter web is solid. I covered the specifics in my Flutter web in production post. For startups looking at WebAssembly-based Flutter web, the performance has improved dramatically with Flutter 3.22+.

Performance That Actually Matters for Startups

Startup founders worry about performance because they've read horror stories about cross-platform apps being "slow." In reality, Flutter compiles to native ARM machine code via Dart's AOT compiler. The runtime performance is within 5% of native Swift/Kotlin for virtually any business app. The things that make startup apps feel slow are almost never the framework:

• Slow API calls — a 2-second endpoint response makes any framework feel slow
• Unoptimized images — loading 4MB photos instead of properly sized thumbnails
• Unnecessary rebuilds — setState on a parent widget that rebuilds 200 children
• Missing pagination — loading 10,000 items at once instead of paginating

// DON'T: Load everything at once
final allProducts = await firestore.collection('products').get();

// DO: Paginate with Firestore cursors
final firstPage = await firestore
    .collection('products')
    .orderBy('created_at', descending: true)
    .limit(20)
    .get();

// Load next page using the last document as cursor
final nextPage = await firestore
    .collection('products')
    .orderBy('created_at', descending: true)
    .startAfterDocument(firstPage.docs.last)
    .limit(20)
    .get();

For deeper performance optimization patterns, my performance guide covers rendering pipeline, memory management, and DevTools profiling.

From Code to App Store — The Last Mile

The code is 70% of the work. The remaining 30% is getting through Apple and Google's review processes. Here's my production checklist — I've refined it through dozens of submissions:

# Pre-submission checklist I use for every startup launch
# Run these commands before building release

# 1. Run all tests
flutter test --coverage

# 2. Analyze code for issues
flutter analyze --no-fatal-infos

# 3. Check for outdated dependencies
flutter pub outdated

# 4. Build release APK/AAB (Android)
flutter build appbundle --release \
  --dart-define-from-file=env/production.json \
  --obfuscate \
  --split-debug-info=build/debug-info

# 5. Build release IPA (iOS)
flutter build ipa --release \
  --dart-define-from-file=env/production.json \
  --obfuscate \
  --split-debug-info=build/debug-info

# 6. Upload to stores
# Android: Upload .aab to Google Play Console
# iOS: Upload via Transporter or Xcode

The --obfuscate flag is critical — it obfuscates your Dart code in the release binary, making reverse engineering harder. --split-debug-info separates debug symbols so your app size stays small while you can still symbolicate crash reports. Both are free and I'm always surprised how many Flutter devs skip them. For the full story on securing your Flutter app before launch, check my security guide.

Mistakes I Made Building Startup MVPs

These cost me time and money. Hopefully they save you both.

Over-engineering the first version. My earliest startup projects had repository patterns, use cases, DTOs, and domain entities for apps with three screens. The architecture was beautiful and the startup ran out of money before launch. Now I use the simplest architecture that handles the current feature set and refactor when (if) the app grows.

Adding packages "just in case." I once added 15 packages to a pubspec.yaml before writing a single feature. Half of them conflicted, three were unmaintained, and the app took 4 minutes to build in CI. Now I add packages per feature as needed. If the feature gets cut, the package goes too.

Skipping proper push notification setup until late. FCM token management, permission handling on iOS vs Android 13+, background message handling, deep linking from notifications — all of this is much easier to wire up during initial development than to bolt on at the end. I now set up the notification skeleton in week one, even if notifications aren't a launch feature.

Not testing on real devices early enough. Simulator performance lies. I once shipped an app that was buttery smooth on the iOS simulator and dropped frames on a real iPhone SE. Now I test on the cheapest device the target audience uses, weekly, from sprint two onward.

Underestimating app store screenshots. Startup founders focus on the app code and forget that the app store listing — screenshots, descriptions, keywords — determines whether anyone downloads it. I now allocate a full day at the end of development for store optimization. It's marketing, not engineering, but it blocks the launch if you don't do it.

When Flutter Is the Wrong Choice

I say this as someone who builds with Flutter every day: it's not always the answer.

Games. Flutter handles simple 2D casual games via Flame, but anything requiring 3D rendering, physics engines, or advanced shaders should use Unity or Unreal Engine. I had a client ask me to build a 3D product configurator in Flutter — I recommended Unity with a Flutter shell and that was the right call.

Pure web apps. If the product is web-only, React with Next.js or even plain HTML/CSS will give better SEO, faster initial load, and a larger developer talent pool. Flutter web is good for internal tools but not for content sites.

Platform-exclusive features. If the core value is watchOS complications, iOS widgets, Android Auto integration, or Wear OS tiles, Flutter's support for these is either missing or experimental. Build those natively.

Brownfield apps. If a startup already has a working native app and wants to add a few features, adding Flutter as a module (add-to-app) introduces complexity that rarely pays off for small additions. It makes sense for large new features, not for fixing a bug in an existing screen.

What Changed in Flutter That Matters for Startups in 2026

Flutter is in a different place than it was two years ago. The changes that matter most for startup teams:

Impeller is the default rendering engine. The old Skia renderer had occasional jank on first render of complex widgets. Impeller pre-compiles all shaders, eliminating shader compilation jank entirely. On iOS this has been stable since Flutter 3.16. On Android it's default since Flutter 3.22. For startups, this means fewer "why does the animation stutter the first time?" bug reports from users.

WebAssembly renderer for Flutter web. The Wasm renderer replaced the old HTML renderer as the default for web builds. It's faster, more consistent across browsers, and closes the performance gap between Flutter web and JavaScript frameworks. For startups building web dashboards alongside mobile apps, this made my recommendation more confident. I did a deep dive on Flutter WASM web performance if you want the benchmarks.

Dart 3 with patterns, records, and sealed classes. Pattern matching and sealed classes eliminated entire categories of boilerplate. Before Dart 3, modeling a network response as Loading/Success/Error required a freezed union or manual subclasses. Now it's built into the language:

// Dart 3 sealed classes — no external package needed
sealed class ApiResult<T> {}
class Success<T> extends ApiResult<T> { final T data; Success(this.data); }
class Failure<T> extends ApiResult<T> { final String message; Failure(this.message); }
class Loading<T> extends ApiResult<T> {}

// Pattern matching for exhaustive handling
Widget buildResult(ApiResult<User> result) {
  return switch (result) {
    Loading() => const CircularProgressIndicator(),
    Success(:final data) => UserProfile(user: data),
    Failure(:final message) => ErrorDisplay(message: message),
  };
}

Material 3 is the default. Material 3 (Material You) with dynamic color theming is now the default theme. Startups get a modern, polished look with minimal custom styling. The ColorScheme.fromSeed() API generates a full palette from a single brand color — I use it for rapid prototyping before the designer delivers the final style guide.

DevTools improvements. Flutter DevTools now includes network profiling, better memory tracking, and the layout explorer that makes debugging responsive layouts dramatically easier. For a startup team where the same developer handles performance and features, these tools save real time.

Flutter's ecosystem has matured to the point where the framework rarely blocks a startup. The blockers are always somewhere else: unclear product requirements, scope creep, backend complexity, or running out of money. Flutter gets you to market fast enough that you have time to figure out those harder problems. If you're interested in polishing your UI with animations after the core MVP ships, or adding Stripe payments to your revenue model, the ecosystem supports all of it from day one.

The best time to start building was yesterday. The second-best time is now. Pick a stack (I gave you mine), pick one feature, and ship something to the app store. Everything else is details you figure out along the way.