Firebase tutorial for solo app developers

You have an app idea and the skills to build the frontend, but backend work stops you cold. You still need authentication and databases. File storage and server setup can slow down the work that makes the app useful.

Firebase, Google's Backend-as-a-Service platform, helps you ship a production app without managing servers. It gives solo developers authentication, databases, hosting, file storage, and serverless code in one toolkit. Firebase is installed in 99.55% of Android apps that use analytics SDKs, so the tooling is widely used. Firebase can help you launch a real backend faster if you understand the cost traps before turning on billing.

What Firebase actually gives you

Firebase removes much of the backend work that blocks solo app developers and bundles the core backend pieces into a unified toolkit, so you can launch a production app without provisioning servers. For a solo developer, this means less infrastructure setup and more time spent on the product itself.

You can adopt each service piece by piece rather than all at once, since each one solves a specific core backend problem.

• Firebase Authentication: User sign-in for common app auth flows, which can fit in under 10 lines.
• Cloud Firestore: A flexible document database for mobile, web, and server apps, trusted by more than 600,000 developers. Use it when your app needs structured data and richer queries.
• Realtime Database: The classic JSON database, synchronized in realtime to every connected client. It fits apps where every client needs the same state quickly.
• Cloud Functions: Serverless code that runs backend tasks, so you do not run your own app servers.
• Firebase Hosting: Web hosting that deploys to a global CDN, with SSL included. Deployment stays simple when you are shipping alone.
• Cloud Storage: Stores user-generated content like photos or videos, with uploads that resume after dropped connections, which matters for mobile users on unstable networks.

How to set up a Firebase project

Create a new Firebase project in the Firebase console before changing code. The console flow connects your app to the backend services it will use, and the setup moves quickly if you follow the order.

Start by creating the project itself, which provisions the backend resources your app will connect to.

1. Sign into the Firebase console and click Create a project.
2. Enter a project name.
3. Review and accept the Firebase terms, then click Continue.
4. Optionally turn on Gemini in Firebase for AI-assisted development.
5. Optionally turn on Google Analytics. Firebase needs it for services such as A/B Testing and Remote Config.
6. Click Create project.

Once Firebase finishes provisioning, you land on the project overview page. Next, register your specific app. For a web app, click the web icon. Enter a nickname, then follow the on-screen SDK setup. An iOS app uses the iOS+ icon and your bundle ID. Android registration runs through the same console flow.

Add the config file and SDK

Configuration files connect your app code to your Firebase project, and they contain unique, but non-secret identifiers for your project. Each platform places the config file differently:

• Android: Drop google-services.json into the module (app-level) root directory.
• iOS/Apple: Add GoogleService-Info.plist to the root of your Xcode project and include it in all targets.
• Web: Paste the Firebase config object into your JS code, copied from the console.

For web, install the SDK through npm:

npm install firebase --save

Then import the services you need:

import { initializeApp } from "firebase/app";
import { getFirestore } from "firebase/firestore";

The libraries are also available via CDN if you want to skip build tools. On iOS, you add the Firebase Apple SDK through Swift Package Manager instead.

Turn on a service

To start with Firestore, expand Build then Firestore database in the console, and click Create database. Pick a location, then start in test mode for open read/write access during early development. Lock it down with Security Rules before launch, since Auth alone does not control database and storage access.

How Firebase Authentication keeps users secure

Firebase Authentication gives you a drop-in UI path and a direct SDK path. FirebaseUI is a drop-in auth tool that handles the full sign-in UI, including edge cases like account recovery and account linking. The direct SDK gives you full control over the experience. FirebaseUI can reduce UI work when you want a standard sign-in flow.

Before any provider works, you turn it on in the console under Authentication > Sign-in method. Email/password supports a configurable password policy with a minimum length from 6 to 30 characters. Email link sign-in removes passwords entirely, which lowers the risk of password reuse across apps. Federated providers such as Google or GitHub need a console toggle to activate, and Apple requires additional setup on its developer portal first.

A Firebase user can link multiple authentication providers to the same account, so someone who signed up with email can later add Google sign-in and keep the same user ID.

Security steps you cannot skip

Auth is only half the job. The other half is locking down what authenticated users can actually touch. When you set up your app databases and storage, initialize your Security Rules to deny all access by default, then grant access as you build. A common rule restricts each user to their own data:

allow read, write: if request.auth != null && request.auth.uid == userId

A few more steps protect you from abuse. Turn on Firebase App Check to block unauthorized clients from reaching your backend. Turn on email enumeration protection so attackers cannot discover which addresses have accounts.

Firebase Auth can stay in the stack even when other pieces move elsewhere, which makes it worth learning well if you plan to switch databases later.

Choosing between Firestore and Realtime Database

Picking the right database now saves you a painful migration later. Cloud Firestore is the preferred database for new projects. Realtime Database still fits a narrower set of cases, so the choice depends on your data model and latency needs.

Firestore stores data in documents organized into collections, which scales cleanly with subcollections and supports chained queries. Realtime Database stores data as JSON in a tree structure with simple lookups only.

The differences go further than data shape. Firestore supports chained filters and sorting, scales automatically, keeps latency low, offers offline support on mobile and web, and bills per operation. Realtime Database is limited to simple lookups, requires manual sharding past its limits, runs at very low latency, supports offline on mobile only, ships with native presence detection, and bills per GB stored and downloaded.

Choose Firestore for most apps, especially anything with rich data or complex filtering. Reach for Realtime Database when you need very low latency or built-in user presence, like a live chat showing who is online. You can also use Firestore and Realtime Database in the same project.

In Firestore, keeping listeners open as long as possible is often the most cost-effective approach, since Firestore bills for documents returned while listeners are active.

What Firebase actually costs

Firebase has two plans. Spark gives you free quotas without requiring a payment method. Blaze is pay-as-you-go, includes all the Spark free quotas, and charges after you exceed them. New Blaze users may receive $300 in free credit. Firebase applies quotas at the project level across apps.

The free Spark tier is generous enough to build and validate a real app:

• Firestore: The Spark quota includes 1 GiB stored, plus daily operation and monthly egress allowances.
• Realtime Database: A free quota covers usage across connections and data.
• Hosting: A free Hosting quota covers storage and transfer, with custom domain and SSL included.
• Authentication: Email and social sign-in free up to 49,999 monthly active users.
• Always free: These tools stay available on both plans:
  • Analytics
  • Crashlytics
  • App Check
  • Performance Monitoring
  • Remote Config
  • Cloud Messaging

These tools help you run the app without adding another paid service.

New projects face plan limits worth checking early. Cloud Functions is not available on Spark and requires Blaze. New projects also need Blaze for Cloud Storage, because Cloud Storage is unavailable on Spark. Spark also caps password reset emails, which can throttle a growing app.

The billing trap every solo developer needs to know

Firebase does not automatically shut off services when you hit a budget threshold. Budget thresholds do not turn off services, because a charge spike might be a bug or might be real growth you do not want to interrupt.

Budget alerts only notify you. Services keep running, and charges can continue. Because Firestore bills per document read, a loop that reads a collection too broadly can rack up reads fast, and the alert arrives after the spending. Before you turn on Blaze, set up budget alerts in the Google Cloud console and treat them as warnings, not spending caps. Then monitor your usage during the early launch period.

How to ship your app without breaking production

Firebase Hosting deploys your app to a global CDN from the command line. Choose the hosting path that matches how your app is built.

Classic Hosting handles:

• Static sites
• Single-page apps
• Sites paired with Cloud Functions

Firebase App Hosting handles full-stack frameworks like Next.js and Angular with GitHub-triggered deployment.

The classic Hosting workflow has a short command sequence:

npm install -g firebase-tools
firebase login
firebase init
firebase deploy

The firebase init command prompts you for a project and public directory, then creates firebase.json and .firebaserc. Deployed sites go live at PROJECT_ID.web.app.

Preview channels and rollbacks protect you when you ship. Preview channels deploy to temporary URLs so you can test with collaborators before going live. If a release breaks something, Hosting provides one-click rollbacks. For a custom domain, you add a TXT record to verify ownership, and Firebase provisions the SSL certificate automatically after verification.

Where Firebase fits and where it does not

Firebase reduces backend overhead substantially for a solo developer. Apps can become unavoidably coupled to Firestore and eventually require rewrites.

A solo founder hit $26k in revenue with a screen-time tool, and a minimalist habit tracker reached $15k in monthly revenue. A small team with 4,500+ paying customers credited serverless Firebase with the heavy lifting.

If you want the fastest path to auth and realtime sync, Firebase earns its place in your stack. It also gives you hosting and managed backend pieces without asking you to run infrastructure yourself. Start on the Spark plan and build the smallest version that solves a real problem. Set budget alerts before you ever turn on Blaze.

If you would rather skip backend configuration entirely and describe your app in plain language, try Anything free, an AI app builder for turning text into working apps, and ship from idea to working app.