Flutter AI App Boilerplate — Ship Without Leaking Keys

Why the proxy matters more than the chat UI

Most Flutter AI tutorials hand you an OpenAI key glued into a Dart constant, then ship it. The problem is that anything compiled into your APK, IPA, or web bundle can be extracted — strings in a release binary, network captures on a rooted device, or the plaintext JS for Flutter Web. The moment your key leaks, a stranger is billing your OpenAI account. This boilerplate's whole reason for existing is the opposite default: the Flutter client never holds a provider key. Instead it talks to a thin Flask proxy you deploy, and the proxy holds the OpenAI and Gemini secrets as server-side environment variables. The app authenticates to your proxy with a Firebase ID token, the proxy verifies it, calls the model, and streams the tokens back. You get to add rate limits, per-user quotas, and a kill switch without shipping a new app build.

What you can build on day one

The AI layer is feature-flagged, so you can ship an AI-first app or bolt intelligence onto an existing flow. Everything below is wired to the proxy, not to a raw key, and streams over the same authenticated channel.

• Streaming ChatGPT-style chat with token-by-token rendering and conversation history
• DALL·E image generation with prompt input and a saved gallery backed by Cloud Storage
• GPT-4 Vision — send a photo, get a structured description or answer
• Gemini as a drop-in alternative provider when you want cheaper or faster responses
• RevenueCat paywall in front of premium AI features, with trials, restore, and entitlements
• GA4 events on every AI call so you can watch cost-per-feature in real numbers

How the architecture stays clean as the app grows

AI calls live behind a repository, injected with get_it, and consumed by Cubits — so your chat screen never imports an HTTP client directly. That separation is what keeps the proxy swappable: today it's Flask in front of OpenAI and Gemini, but because you own the source you can point the same repository at Supabase Edge Functions, Cloudflare Workers, or your own Node service without touching a single widget. The streaming responses flow into BLoC state, the UI rebuilds incrementally, and errors (rate limits, timeouts, model refusals) surface as typed states you handle once. Material 3 theming with centralized design tokens means the chat bubbles, the image gallery, and the paywall all retheme from one file.

• BLoC + Cubit state for streaming, retries, and typed error handling
• Repository pattern so the proxy backend is swappable without UI changes
• Firebase ID token auth on every proxy request, verified server-side
• Impeller-rendered, responsive layouts that hold up on phone, tablet, and web

When a raw-key setup or a no-code tool is the better call

Honesty first: if you're building a throwaway hackathon demo that never reaches a store and never bills real money, deploying a proxy is overkill — a hardcoded key in a private repo is faster and fine for 48 hours. If you've never written Dart and you want to drag-and-drop a chatbot UI without owning any backend, FlutterFlow (marketed as a visual builder) gets you a clickable prototype sooner, though you'll hit the same key-exposure question the moment you go to production. And if your AI needs are a single, occasional call rather than a streaming chat product, a managed backend-as-a-service with built-in AI gateways may save you from running any proxy at all. This boilerplate is for the case in between: you want a real, ownable, store-ready Flutter app where the AI is a first-class feature and the keys are genuinely safe.

The Flutter Kit vs. wiring AI yourself from scratch

Frequently Asked Questions