How to Build a Full-Stack App with Claude Code and Firebase (2026)

Who This Guide Is For

This is not a beginner introduction to Claude Code.

If you've already used Claude Code to build something — even something small — and you're ready to graduate to a production-grade full-stack app with real auth, a live database, and a deployed URL, this is your guide.

The stack: Claude Code + Firebase + Next.js + Vercel. It's the fastest path from idea to something real users can sign into and use. Every component is free to start. Firebase Spark plan handles the database and auth at zero cost until you're past prototype. Vercel deploys in 30 seconds.

Here's what you'll build by the end of this walkthrough:

• A Next.js app with Firebase Auth (email/password + Google Sign-In)
• A Firestore database that reads and writes user-specific data
• At least one authenticated route (only signed-in users can see it)
• A deployed live URL on Vercel

Real timeline: Marcus B. went from blank folder to deployed app with auth and a working data layer in a single 5-hour session. Jordan S. built the same stack in two 2-hour sessions over a weekend. Aisha W. had her first version deployed before she fully understood what Firestore was.

That's the bar. Let's build.

Step 1: Scaffold the Next.js App with Claude Code

Open your terminal in a clean folder and run:

claude

Start with this prompt:

*"Create a new Next.js 14 app using the App Router. Set up the project structure with a src/ directory. Include Tailwind CSS. Create a basic layout with a header and a placeholder home page. Don't install Firebase yet — I'll add that in the next step."*

Claude Code will scaffold the entire project. When it's done, run:

npm install
npm run dev

You should have a running app at localhost:3000. If anything breaks during install, paste the error into Claude Code and ask it to fix it. Don't try to debug it manually at this stage.

Why this prompt works:

Breaking the scaffold into steps (Next.js first, Firebase second) keeps the first task small enough to verify before adding complexity. You now have a working baseline to build on. This is the most important habit in full-stack development with Claude Code: verify each layer before adding the next.

Step 2: Add Firebase Auth

Go to the Firebase Console (console.firebase.google.com). Create a new project. In Authentication → Sign-in method, enable Email/Password and Google.

Get your Firebase config object from Project Settings → Your apps → Add app → Web.

Now go back to Claude Code with this prompt:

*"Add Firebase to this Next.js app. I want Firebase Auth with email/password and Google Sign-In. Here's my Firebase config: [paste your config object]. Create a lib/firebase.ts file that initializes Firebase and exports the auth instance. Create an AuthContext that wraps the app and exposes the current user. Add a sign-in page at /login with email/password form and a Google Sign-In button. Redirect to /dashboard after successful auth. Protect the /dashboard route so only signed-in users can see it."*

This is a substantial prompt — and that's intentional. Auth has a lot of moving pieces and they need to be wired together consistently. Claude Code handles this well when the full scope is clear upfront.

What Claude Code will build:

• lib/firebase.ts — Firebase initialization
• lib/auth-context.tsx — AuthContext with user state
• app/login/page.tsx — Login form with Google button
• app/dashboard/page.tsx — Protected route
• Middleware or auth guard to redirect unauthenticated users

Test it before moving on. Sign in with a test email. Sign in with Google. Sign out. Confirm the /dashboard route redirects to /login when you're not signed in. If anything is broken, describe the specific behavior to Claude Code and ask for a fix.

Step 3: Add Firestore (The Database Layer)

In Firebase Console → Firestore Database → Create database. Start in test mode (you'll tighten security rules later).

Now tell Claude Code what data your app needs to store. Here's where you think about your specific product, not a generic database. For this walkthrough, we'll use a simple example: a user's saved notes.

Prompt:

*"Add Firestore to this app. I want a simple notes feature. Each signed-in user can create, read, update, and delete their own notes. Each note has: a title, body text, and a createdAt timestamp. Use the Firestore collection structure: users/{userId}/notes/{noteId}. Create a NotesList component that fetches the current user's notes in real time using onSnapshot. Create a CreateNote form that adds a note to Firestore. Create a DeleteNote button for each note. All Firestore reads and writes should be scoped to the authenticated user's ID."*

Key phrase in that prompt: "All Firestore reads and writes should be scoped to the authenticated user's ID."

This is a security principle, not just a code pattern. Without this, one user can read another user's data. Claude Code will enforce this with the userId filter, but you need to verify it.

Test this step:

1. Sign in as User A. Create two notes.
2. Sign out. Sign in as User B (create a second test account).
3. User B's notes list should be empty — not showing User A's notes.

If User B can see User A's notes, the query is not scoped correctly. Tell Claude Code: "User B can see User A's notes. Fix the Firestore query to only return notes where userId matches the current user's auth uid."

Step 4: Firestore Security Rules

Test mode Firestore allows anyone to read and write. Before you deploy anything real, you need security rules.

Prompt:

*"Write Firestore security rules for this app. Requirements: (1) Users can only read and write documents in their own users/{userId}/notes subcollection. (2) No user can read another user's data. (3) All writes must include a userId field that matches the authenticated user's uid. Give me the complete rules file."*

Claude Code will return a rules file. Copy it into Firebase Console → Firestore Database → Rules and publish it.

Test the rules work:

In Firebase Console → Firestore → Rules playground, try to read a document as an unauthenticated user. It should be denied. Try as the correct user. It should be allowed.

This step takes 10 minutes and protects your users' data. Skip it and you have a production app with no access control. Don't skip it.

The pattern for every feature you add:

Every time you add a new Firestore collection, update the security rules before you deploy. Claude Code can help: *"I added a new collection called posts. Update the security rules so only authenticated users can read their own posts."*

Step 5: Deploy to Vercel

You have a working full-stack app with auth and a database. Time to make it live.

Prepare environment variables:

Your Firebase config has API keys that shouldn't be committed to git. Prompt:

*"I need to move my Firebase config values into environment variables for Vercel. Create a .env.local file with the correct variable names (NEXT_PUBLIC_ prefix for values needed on the client). Update lib/firebase.ts to read from process.env. Generate a .env.example file with placeholder values. Make sure .env.local is in .gitignore."*

Verify the app still runs locally after this change. Then:

1. Push your code to a GitHub repo (new repo, public or private)
2. Go to vercel.com → Add New → Project → Import from GitHub
3. In Environment Variables, add each variable from your .env.local
4. Deploy

Vercel builds and deploys in about 60 seconds. Your app is live at a vercel.app URL.

Test the live deployment:

• Sign in with email/password
• Sign in with Google (you may need to add your Vercel URL to Firebase's authorized domains: Firebase Console → Authentication → Settings → Authorized domains)
• Create a note. Confirm it saves.
• Sign out. Confirm redirect to /login.

If Google Sign-In fails on the live URL, it's almost always the authorized domains issue. Go to Firebase Console → Authentication → Settings → Authorized domains, and add your Vercel URL.

Step 6: The Gap Between Prototype and Product

You now have a deployed full-stack app. Here's what separates a prototype from something you can charge for.

What your prototype has:

• Auth that works
• A database that reads and writes
• A live URL

What a product needs:

• A specific problem it solves (your notes app doesn't solve a problem yet — it's a generic CRUD app)
• A reason for someone to give you their email address and create an account
• One workflow that delivers clear value in under 5 minutes

Marcus started with a notes app. Then he added a CRM layer: notes tied to client names, automatic follow-up reminders, a dashboard that showed which clients hadn't heard from him in 14 days. That's the moment it became a product someone would pay for. The tech is the same. The specificity is what changed.

Jordan built an internal dashboard for his consulting clients. Generic dashboard → specific dashboard for one client → feature that the client said "I check this every morning." That morning-check habit is worth $200/month.

Aisha W. built a client intake form. Generic form → form that synced responses to a Firestore collection → automated email confirmation via Resend when a new intake submitted → weekly digest for Aisha showing all pending intakes. From form to $3,000/month recurring in 6 weeks of iteration.

The stack you just built can do all of this. The next question is never "can Claude Code build it" — it's "what problem am I solving and for whom?"

What to Build Next (And How to Get Unstuck)

Once the foundation is in place, every new feature follows the same pattern in Claude Code:

1. Describe the feature in terms of what the user does, not what the code does
2. Tell Claude Code the relevant data already in Firestore
3. Ask it to extend the existing architecture — not start fresh

Prompt pattern that works:

*"I have a Next.js app with Firebase Auth and Firestore. The current data structure is: users/{userId}/notes/{noteId}. I want to add [specific feature]. The feature should: [what it does]. It should read/write to Firestore at [collection path]. Use the same AuthContext I already have. Don't change the existing components — add the new feature as a new page at /[route]."*

Common places people get stuck:

*"I can't figure out the right Firestore query for [thing]."* → Describe the data structure and what you want to return. Claude Code will write the query.

*"Auth stops working after I add a new feature."* → The most common cause is reading the user from state before the auth state has loaded. Ask Claude Code to add an auth loading state check before rendering protected content.

*"My app works locally but not on Vercel."* → Environment variable names are usually the issue. Ask Claude Code to audit your env var usage and confirm all client-side vars have the NEXT_PUBLIC_ prefix.

Every one of these blockers is Claude Code territory. The right move is always to describe the specific symptom, not the underlying cause. You don't need to understand the cause — you need to describe what's happening.

---

If you want to build a real product — not just practice the stack — Xero Coding is a 4-week cohort where you go from blank folder to deployed product with real users. Live sessions, max 30 students, with builders doing the same work in parallel.

Use EARLYBIRD20 at [/bootcamp](/bootcamp) for 20% off.

Or book a 30-minute call: [Book a free call](https://calendly.com/drew-xerocoding/30min) — no pitch, just a conversation about your idea and what makes sense for your stage.