The first time I tried Build Mode, the preview panel stayed completely white for five minutes. No error message, no spinner, just blank space where my app was supposed to appear. I'd been building iOS and Android apps independently for years, but this kind of silent failure was harder to debug than a stack trace.
What makes Build Mode tricky is that problems can come from several different layers at once: the browser environment, the Firebase project configuration, the generated code itself, or the deployment settings. This guide breaks each failure mode down by where it happens, with concrete steps to fix it.
Blank Preview Panel
A blank preview after sending a prompt is the most commonly reported Build Mode issue. There are three likely causes.
Cause 1: JavaScript runtime error in generated code
When generated code contains a syntax error or references an undefined variable, the preview iframe fails to render and shows nothing. Open DevTools to check.
Steps:
1. Press F12 to open DevTools while Build Mode is open
2. Go to the Console tab
3. Look for red error messages
A common one looks like this:
TypeError: Cannot read properties of undefined (reading 'map')
This happens when generated code calls .map() on data before it's been loaded. Gemini sometimes skips loading state handling. You can fix it with a targeted prompt:
"Add proper loading state handling and undefined checks before calling .map() on any data."
Cause 2: Browser extension interference
Content blockers and script injection extensions can interfere with Build Mode's iframe communication. Test in an incognito window (extensions disabled by default) to confirm.
1. Open Ctrl+Shift+N (Mac: Cmd+Shift+N) for incognito
2. Go to aistudio.google.com and try Build Mode again
3. If it works, disable extensions one by one to identify the culprit
Cause 3: Expired session
If your Google account session has timed out, API calls will silently fail. Close the tab, sign back in, and try again.
Prompts That Don't Change Anything
You ask to change a button color or resize a font, and nothing happens. The code and preview stay identical.
This is usually context bloat. As you keep editing in the same Build Mode session, the conversation history grows. Eventually, Gemini starts treating small change requests as already processed or conflicting with earlier instructions.
Two ways to fix this:
First, use the "Reset Context" button at the top of the conversation. This clears chat history while keeping your current code intact.
Second, make instructions more specific. Vague requests get ignored more often than precise ones:
❌ Vague:
"Make it simpler"
✅ Specific:
"Change the header background color to #1a73e8.
Set button padding to 8px 16px."
App Doesn't Work After Firebase Deployment
Build Mode can push directly to Firebase Hosting, but deployed apps often break in ways they didn't in preview. Two patterns account for most of these failures.
Pattern 1: Environment variables not available on Hosting
Generated code sometimes reads Firebase configuration from environment variables like process.env.VITE_FIREBASE_API_KEY. This works locally with a .env file, but Firebase Hosting doesn't support server-side environment variables for static sites. The value becomes undefined in production.
// This breaks on Firebase Hosting
const firebaseConfig = {
apiKey: process.env.VITE_FIREBASE_API_KEY, // undefined in production
authDomain: process.env.VITE_FIREBASE_AUTH_DOMAIN,
};The fix is to inline the values directly. Firebase API keys in frontend code are intentionally public — Firebase's security model relies on security rules, not key secrecy:
// Safe to inline for frontend Firebase usage
const firebaseConfig = {
apiKey: "AIzaSy_YOUR_ACTUAL_KEY",
authDomain: "your-project.firebaseapp.com",
projectId: "your-project-id",
};Pattern 2: Firestore security rules blocking writes
If you get a permission-denied error when writing to Firestore, the security rules are likely still at the default (deny all). Update them in Firebase Console → Firestore Database → Rules.
// Development-only rule — tighten before launch
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}Manual Code Edits Getting Overwritten
After editing code manually in the Code tab, your next prompt overwrites your changes. This happens because Build Mode applies diff patches when updating code. Manual edits that conflict with a patch's target area get replaced.
Add comments to protect critical sections:
// ★ Manually optimized — do not modify this function
function customCalculation(data) {
// important logic
}After significant manual changes, also tell Gemini explicitly to treat the current code as the baseline:
"Using the current code as the starting point, add [feature] without changing the existing customCalculation function."
Code Disappears After GitHub Export
Build Mode's GitHub Export sends your current code to a repository. But it's a one-way push — changes you make in GitHub won't come back into Build Mode. If you push from Build Mode again later, it will overwrite what's in GitHub.
The practical workflow that avoids this:
1. Use Build Mode to generate the initial structure
2. Export to GitHub (treat this as "graduating" the code out of Build Mode)
3. Clone locally and continue in a normal development workflow
4. Don't return to Build Mode for that project (or use a separate branch for experiments)
As an indie developer who's shipped apps since 2014, I've found that working with a tool's intended design rather than around it tends to save more time than it costs.
Build Never Finishes (Timeout)
Asking for a fully-featured app in a single prompt often causes Gemini's generation to stall or time out. The more complex the request, the more likely an incomplete or broken result.
Build incrementally:
Step 1: "Create a simple product listing page"
Step 2: "Add an add-to-cart button and a cart sidebar"
Step 3: "Integrate Stripe checkout"
Step 4: "Add Firebase Auth for user login"
One feature per prompt produces more reliable code and makes it easier to catch problems early. After switching to this approach, most of my Build Mode sessions stopped failing mid-generation.
Know What Firebase Auto-Integration Creates Behind the Scenes
When you tell Build Mode "save this data" or "let users log in," the Antigravity agent decides whether a backend is needed and proposes Firebase integration. Knowing exactly what gets created the moment you click "approve" makes it much faster to diagnose the permission-denied errors and post-deploy config issues described above.
Approving kicks off four things at once behind the scenes:
- Creating a new Firebase project (or letting you pick an existing one)
- Enabling Cloud Firestore with an initial set of security rules
- Enabling Firebase Authentication and registering the Google provider
- Wiring the Firebase SDK into the generated code
This provisioning can take a few tens of seconds. If the preview seems to freeze for a moment while a project is being created, that is not a failure — as long as there are no red errors in the DevTools console, give it a little time before assuming it hung.
Right after approving, it is worth confirming three things. They make later debugging of permission-denied or broken deploys far quicker:
Post-approval checklist:
1. Which project did Firebase Console actually create? (not the wrong existing one)
2. Are the Firestore rules still the loose, temporary defaults?
3. Is the Google provider enabled under Authentication > Sign-in method?
The second point matters most. The auto-set initial rules are usually loosened for development, and shipping them as-is leaves your database open to anyone. Tighten them to auth-based rules before release, as covered in the security rules section above.
As an indie developer, I have learned to decide up front which parts I let Build Mode own and which parts I lock down myself. I once left the auto-generated permissive rules in place until right before launch, and only caught them during a final pre-release check.
Where to Start When Nothing Works
If you're stuck and not sure which problem you're dealing with, this sequence usually gets you unstuck quickly:
- Open DevTools (F12) → Console. Look for red errors before anything else.
- Try incognito mode to rule out extension interference.
- If Firebase-related, check that security rules aren't blocking access.
- Reset the conversation context if prompts aren't applying.
The first step — DevTools console — resolves the majority of blank preview cases on its own.