Every mobile app has a backend; the question is not whether there will be one, but who builds it. Short answer: for an MVP built by a single team, with few business rules and a simple data model, a backend-as-a-service (BaaS) such as Firebase or Supabase is the fastest route. If there are several clients (mobile plus a web panel plus third parties), business rules that must run on the server, integrations such as ERP or e-invoicing, relational reporting and obligations about where data lives, you need a custom backend. In most corporate projects the right answer is hybrid: Firebase for push notifications, crash reports and analytics, your own API for core data and business rules. This article explains how we make that call in mobile app projects.
What does a backend do for a mobile app?
The app on the phone is only the interface; everything persistent lives on a server. The backend takes on these jobs:
- Authentication and sessions: who the user is, which device they signed in from, when the session ends.
- Data storage and queries: orders, messages, profiles, including two users editing the same record at once.
- Business rules: price calculation, stock deduction, approval flows, limit checks. Running these on the client is a security hole.
- Files and media: photo upload, resizing, access permissions.
- Notifications and scheduled jobs: push, email, reports that run overnight.
- Integrations: payment provider, shipping, accounting, ERP; the keys for these connections cannot live in the mobile bundle.
A backend service covers the first, second and fourth items very well, and the third and sixth only with extra code. The decision is built on that gap.
What BaaS (Firebase, Supabase) gives you and what it does not
Firebase is a bundle of services hosted by Google: Authentication, Firestore (a document database), Storage, Cloud Functions, Cloud Messaging (push), Crashlytics and Analytics. Supabase builds a similar bundle on PostgreSQL and is open source. In both you manage no servers; the mobile app connects to the database directly through the SDK, and access rules are defined on the service side. What you get is clear: a first release in days instead of weeks, no authentication or real-time sync to write, no scaling to think about. What you do not get shows up later in the project: Firestore has no joins and no bulk reporting, the data model is built around screens and every new screen strains it; multi-step business rules still mean writing Cloud Functions; moving the data to another system is possible, but going from a document structure to a relational one is a project of its own. Supabase solves the first problem by offering a relational database, but the business rule and integration question is the same there.
The critical difference: where do business rules run?
In the BaaS model the app writes to the database directly. This is the fastest and the most dangerous feature. In an ordering app, if the phone calculates the total and writes it to Firestore, anyone who opens the app can change that total and send it; security rules check field types and ownership, but a rule like “the total must equal the sum of price times quantity over the lines” is hard to express readably. The fix is to move the write into a server function:
// Cloud Function: the total is not taken from the client, it is computed on the server
import { onCall, HttpsError } from 'firebase-functions/v2/https';
import { getFirestore } from 'firebase-admin/firestore';
export const createOrder = onCall(async (req) => {
if (!req.auth) throw new HttpsError('unauthenticated', 'Sign-in required');
const db = getFirestore();
const items = req.data.items as { productId: string; qty: number }[];
return db.runTransaction(async (tx) => {
let total = 0;
for (const item of items) {
const snap = await tx.get(db.doc('products/' + item.productId));
if (!snap.exists) throw new HttpsError('not-found', 'Unknown product');
const product = snap.data()!;
if (product.stock < item.qty) {
throw new HttpsError('failed-precondition', 'Insufficient stock');
}
total += product.price * item.qty; // price comes from the record, not the phone
tx.update(snap.ref, { stock: product.stock - item.qty });
}
const ref = db.collection('orders').doc();
tx.set(ref, { userId: req.auth!.uid, items, total, createdAt: new Date() });
return { orderId: ref.id, total };
});
});The moment you write this function you are writing a backend; only the hosting is Google’s. As the number of business rules grows, functions multiply, the shared code and test setup between them need a framework, and the project turns into a custom backend without anyone deciding it. That is why the decision does not start with “Firebase or my own server” but with “how many of my business rules must run on the server”. We covered the mobile security principles in mobile app security and API design in REST or GraphQL.
A backend service does not remove business rules; it only changes where they are written. Once the number of rules that must run on the server exceeds a handful, the speed the service gave you starts being paid back.
What drives the cost?
BaaS pricing is per usage: reads, writes, storage and function invocations. A custom backend has fixed server and maintenance costs. We give no figures, because the two bills are driven by different things, and knowing that matters more than the number. A BaaS bill grows with the data model, not the user count: if a list screen reads a hundred documents every time it opens, the daily reads per user depend on that screen’s design, and this is the most expensive mistake to fix after launch. The cost of a custom backend grows not with transaction volume but with the time of the team that writes and maintains it. We itemised the yearly costs in mobile app maintenance cost; for the initial development budget see mobile app development cost.
Is the data yours? Portability and location
Every project on a BaaS should answer three questions up front. First, which country the data sits in: Firebase projects let you choose a region, but transferring personal data abroad is a separate obligation under Turkish data protection law (KVKK), to be covered by your privacy notice and, where required, explicit consent (this article is not legal advice). Second, how the data is exported: we described moving from a document database to a relational one in data migration; it can be done, but a data model built around screens gets redesigned as it turns into tables. Third, what happens when the service retires a feature: Firebase Dynamic Links was shut down and the apps that depended on it rebuilt their linking infrastructure. That does not make the service bad; it shows that a vendor’s product decision can reach your product. Put the exit cost in writing before tying a critical flow to a single provider.
The decision test: three questions
If you answer “yes” to at least two of the following, put the core data on a custom backend:
- Will clients other than the mobile app use the data: a web admin panel, a dealer portal, a third-party API, an accounting or ERP integration?
- Are there business rules that must run on the server: price and discount calculation, stock reservation, approval flows, limit checks, ordered transactions?
- Is relational reporting needed: revenue by date range, averages per user, management reports that join several tables?
A fourth question applies on both paths: can you export the data today with a single command? If not, fix that first whatever model you choose. With fewer than two “yes” answers, and especially if you want to get a first release to market quickly and measure demand, BaaS is the right start; we described MVP scope in what is an MVP. If a database choice comes up, PostgreSQL or MySQL helps.
The hybrid model: using both
In practice the most common setup is this: Firebase Cloud Messaging for push, Crashlytics for crash reports, Analytics for usage; your own API for identity, core data and business rules. In this model the mobile app never connects to Firestore; Firebase only provides the device-side helper services. We covered the push setup in push notifications and the design that keeps working without a connection in offline-first mobile apps. The hybrid model has one condition: the boundary must be explicit. Which data is owned by Firebase and which by the API must be written down from day one; otherwise the same information lives in two places and nobody knows which one is right.
Conclusion
Firebase and similar services are genuine tools that speed up a mobile app’s first release; the problem is not the tool but the decision left unmade. When a business rule has to move to the server, when a second client arrives or when the first management report is requested, the project has already become a custom backend, and doing that deliberately is cheaper than doing it by accident. Write to us through the quote form to map out which of your app’s data belongs where; we will answer the three questions above together in the first meeting.