# 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](https://firebase.google.com/docs/functions). It gives solo developers authentication, databases, hosting, file storage, and serverless code in one toolkit. Firebase is installed in [99.55% of Android apps](https://www.statista.com/statistics/1035612/leading-mobile-app-analytics-sdks-android) 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](https://firebase.google.com/docs/functions). 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](https://www.anything.com/docs/apps/backend) problem.

- **Firebase Authentication:** User sign-in for common app auth flows, which can fit in [under 10 lines](https://firebase.google.com/products/auth).
- **Cloud Firestore:** A flexible document database for mobile, web, and server apps, trusted by more than [600,000 developers](https://firebase.google.com/docs/database/rtdb-vs-firestore). Use it when your app needs structured data and richer queries.
- **Realtime Database:** The classic JSON database, [synchronized in realtime](https://firebase.google.com/docs/database) 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](https://firebase.google.com/docs/hosting), with SSL included. Deployment stays simple when you are shipping alone.
- **Cloud Storage:** Stores user-generated content like [photos or videos](https://firebase.google.com/docs/storage), 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](https://console.firebase.google.com/) 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](https://firebase.google.com/docs/android/setup) 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](https://firebase.google.com/docs/android/setup) 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](https://www.anything.com/docs/apps/web), click the web icon. Enter a nickname, then follow the [on-screen SDK setup](https://firebase.google.com/docs/web/setup). An [iOS app](https://firebase.google.com/docs/ios/setup) 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](https://firebase.google.com/docs/ios/setup) 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](https://firebase.google.com/docs/firestore/quickstart) through npm:

```bash
npm install firebase --save
```

Then import the services you need:

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

The libraries are [also available via CDN](https://firebase.google.com/docs/web/learn-more) 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](https://firebase.google.com/docs/firestore/quickstart) 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](https://firebase.google.com/docs/auth/where-to-start) 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](https://firebase.google.com/docs/auth/web/password-auth). Email link sign-in removes passwords entirely, which lowers the risk of [password reuse](https://firebase.google.com/docs/auth/ios/email-link-auth) across apps. Federated providers such as Google or GitHub need a console toggle to activate, and [Apple requires additional setup](https://firebase.google.com/docs/auth/web/apple) on its developer portal first.

A Firebase user can link [multiple authentication providers](https://firebase.google.com/docs/auth/ios/account-linking) 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](https://www.anything.com/docs/apps/databases) and storage, [initialize your Security Rules](https://firebase.google.com/support/guides/security-checklist) to deny all access by default, then grant access as you build. A [common rule](https://firebase.google.com/docs/rules/basics) restricts each user to their own data:

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

A few more steps protect you from abuse. Turn on [Firebase App Check](https://firebase.google.com/support/guides/security-checklist) to block unauthorized clients from reaching your backend. Turn on [email enumeration protection](https://firebase.google.com/docs/auth/web/password-auth) so attackers cannot discover which addresses have accounts.

## Choosing between Firestore and Realtime Database

Picking the right database now saves you a painful migration later. Cloud Firestore is the [preferred database](https://firebase.google.com/docs/database/rtdb-vs-firestore) 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](https://firebase.google.com/docs/firestore), 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.

## What Firebase actually costs

Firebase has [two plans](https://firebase.google.com/pricing). 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](https://firebase.google.com/docs/projects/billing/firebase-pricing-plans). Firebase applies quotas at the [project level](https://firebase.google.com/pricing) across apps.

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

- **Firestore:** The Spark quota includes [1 GiB stored](https://firebase.google.com/docs/firestore/pricing), 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](https://firebase.google.com/docs/auth).
- **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.

### The billing trap every solo developer needs to know

Firebase [does not automatically](https://firebase.google.com/docs/projects/billing/avoid-surprise-bills) shut off services when you hit a budget threshold. Budget thresholds [do not turn off](https://firebase.google.com/docs/projects/billing/avoid-surprise-bills) 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](https://firebase.google.com/docs/firestore/pricing), 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](https://firebase.google.com/docs/hosting) to a global CDN from the command line. Choose the hosting path that matches how your app is built.

Classic Hosting handles:

- [Static sites](https://firebase.google.com/docs/hosting/quickstart)
- [Single-page apps](https://firebase.google.com/docs/hosting/quickstart)
- Sites paired with Cloud Functions

The classic Hosting workflow has a short command sequence:

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

### Where Firebase fits and where it does not

Firebase reduces backend overhead substantially for a solo developer. Apps can become [unavoidably coupled](https://news.ycombinator.com/item?id=24637097) to Firestore and eventually require rewrites.