fireact.dev: a React and Firebase SaaS starter with a Claude Code skill

What the framework gives you on the first day

fireact.dev is described as a comprehensive open source framework for building production-ready SaaS applications with Firebase, React, TypeScript and Stripe integration, and the overview frames it as a complete foundation that combines industry-standard technologies and best practices so you can launch a SaaS product faster.

The feature list is grouped into three areas and the first one covers the work that every SaaS needs and every founder rebuilds badly. Authentication and user management includes a complete authentication system with sign-up, sign-in and password reset, user profile management, role-based access control, and team member invitations with permissions.

The second group is subscription management: multiple subscription plans, Stripe integration for payment processing, a billing portal with invoice management, payment method management, and subscription upgrades and downgrades.

The third is the one that distinguishes this from a plain starter template. There is a built-in Claude Code skill for post-installation customisation, natural language commands to add pages, components, navigation, Cloud Functions and more, and 8 customisation playbooks with step-by-step guidance. You invoke it with the slash command /fireact-builder, or let it auto-detect your project.

The developer experience section lists TypeScript for code quality, TailwindCSS for responsive design, Firebase emulator support for local development, comprehensive documentation and a modular architecture.

The homepage is fireact.dev, and there is a demos page with live demonstrations of both the Core and SaaS versions. The project is MIT licensed, the last push was on 2026-09-11, and there are no GitHub releases.

The repository is four projects in one tree

The repository structure section explains the layout, and it is worth reading because it tells you which part of the repository you actually depend on.

The source/ directory contains the complete, combined source code for the project, both the React frontend application and the Firebase Cloud Functions backend code. It follows a monorepo structure with packages/app for the React app and packages/functions for the Cloud Functions. The word combined matters: this is a single repository holding both halves, not a front end that talks to a separately hosted backend, which is what a Firebase deployment shape tends to produce.

create-fireact-app/ is the CLI tool used to scaffold new Fireact applications, and it is published separately as an npm package, which is why the install command is a global npm install rather than a path into this repository.

website/ is the main marketing website for fireact.dev, built with Hugo. docs/ is the documentation website, also built with Hugo. And demo/ contains the demo application.

Using Hugo for both the marketing site and the docs is a deliberate choice. The same static site generator means the docs and the marketing pages share a build pipeline, a template set and a deployment story, so a documentation change and a marketing change are the same kind of commit.

The top level listing shows the other files. There is an ARCHITECTURE.md and a DIAGRAMS.md at the root, a TROUBLESHOOTING.md, a CONTRIBUTING.md, a .gitmodules, and the saas-demo.png screenshot that appears near the top of the README.

The presence of .gitmodules tells you the source/ directory itself pulls in further submodules, which is consistent with the source tree being assembled from separately developed pieces.

Creating a project and running it against the emulators

The getting started flow is four steps, and the first two are the CLI.

Install the CLI globally:

   npm install -g create-fireact-app

Then create a project:

   create-fireact-app <your-project-name>

The CLI guides the setup, including the Firebase and Stripe configuration, and you follow the prompts to select your Firebase project and configure Stripe. After creation you move into the new directory:

   cd <your-project-name>

Then you build the application and the functions and start the emulators:

   npm run build && cd functions && npm run build && cd ..
   firebase emulators:start

Running the whole thing locally against the Firebase emulator suite is the point of that step. It means you can develop and test a Stripe-backed subscription flow without a deployment and without touching a live Stripe account, which is the single most valuable thing about a Firebase-based stack for a solo developer.

For Stripe webhook testing, the README has a separate command to run in another terminal:

   stripe listen --forward-to http://127.0.0.1:5001/<your-firebase-project-id>/us-central1/stripeWebhook

And there is a follow-up that catches people out. You have to update functions/src/config/stripe.config.json with the new webhook endpoint secret and rebuild the functions if the webhook secret changes, with the rebuild being cd functions && npm run build. The stripe listen tool generates a fresh signing secret on every run, so without that step your webhook handler keeps rejecting the events as unsigned.

The stack behind all of it is React, TypeScript and TailwindCSS on the frontend, Firebase with Authentication, Firestore and Cloud Functions on the back end, Stripe for payments, and Vite, ESLint and PostCSS as the development tools.

Deploying, and the three configuration changes that matter

The deployment section is thorough, and the ordering is deliberate.

Before deploying to production there are three configuration changes. Replace the emulator settings with the production Firebase config, use the production Stripe API keys, and set emulators.enabled to false in firebase.config.json. That last one is the easy detail to forget, and forgetting it means a production build still tries to talk to a local emulator.

Then you build both halves separately, because the React app and the Cloud Functions are two build outputs:

   cd <your-project-name>
   npm run build
   cd functions
   npm run build
   cd ..

And you can test that production build locally before it goes anywhere, with the hosting emulator only:

   firebase emulators:start --only hosting

The deployment commands themselves are the standard Firebase CLI ones, and the README shows both the everything variant and the per-service variants, with the comments explaining what each covers:

# Deploy everything
firebase deploy

# Or deploy specific services
firebase deploy --only hosting        # React app
firebase deploy --only functions      # Cloud Functions
firebase deploy --only firestore      # Security rules & indexes

And the incremental variant, which is the one you will actually use day to day, deploys only what changed:

# Deploy only what changed
firebase deploy --only hosting,functions

The environment-specific section handles the staging and production split with Firebase aliases, so you add the aliases with firebase use --add, switch to staging, deploy, then switch to production and deploy. The alias mechanism is what keeps a single set of Firebase config files pointing at different projects.

CI, the webhook endpoint and what to check after deploying

Two CI paths are documented. The first is GitHub Actions, with a workflow file you create yourself, and the README gives it in full.

name: Deploy to Firebase

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: |
          npm install
          cd functions && npm install

      - name: Build
        run: |
          npm run build
          cd functions && npm run build

      - name: Deploy to Firebase
        uses: w9jds/firebase-action@master
        with:
          args: deploy
        env:
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

The token comes from firebase login:ci, and you save it as the GitHub secret FIREBASE_TOKEN. The Node version in the workflow is 18, and the third party action is pinned to the master branch rather than to a tag, which is worth changing before you rely on it in a pipeline that deploys to production.

The alternative is Google Cloud Build, and the README points at the demo README for the detailed setup with secure configuration management, which suggests Cloud Build is the path with the better security story and the demo is the worked example.

After a deployment, the README lists five things to verify: the hosting URL, which takes the form https://your-project.web.app, the authentication flow, the Cloud Functions, the Firestore connectivity, and the Stripe webhooks.

The production webhook is set up separately, with the endpoint in the Stripe dashboard pointing at the deployed function:

# Add webhook endpoint in Stripe Dashboard
https://us-central1-your-project.cloudfunctions.net/stripeWebhook

# Use production webhook secret in stripe.config.json

And for monitoring, the README lists the Firebase Console functions logs and analytics, the Stripe Dashboard webhooks section, and error tracking with Sentry or LogRocket recommended. That last one is the one a lot of Firebase projects skip and then regret, because a Cloud Function that throws is invisible until a customer reports it.

Editorial conclusion

Adopt fireact.dev if you are starting a SaaS product on Firebase and Stripe and want the auth, team and billing plumbing already written, and you are willing to work inside the Firebase platform's constraints. Do not adopt it if you need a different backend, because the persistence, auth and functions all run on Firebase, and treat the Claude Code skill as an aid rather than a guarantee, since it generates changes you still have to review and build. Before your first deploy, replace the emulator configuration with production values, set emulators.enabled to false, and swap the Stripe keys, and check the TROUBLESHOOTING.md and ARCHITECTURE.md files in the repository.

Frequently asked questions

Official sources

1. fireact-dev/main on GitHub
2. Issues
3. License: MIT
4. Project website
5. README