Backend-as-a-Service (BaaS)

Build the mental model

BaaS describes a platform category that provides the common building blocks of a backend as ready-made services you connect to, rather than infrastructure you build yourself.

Authentication (signup, login, sessions)
Database (structured or document storage)
File storage
Realtime updates
Simple serverless functions for custom logic

Mental model: Frontend -> BaaS, branching into Auth, Database, Storage, and Realtime as distinct but integrated services.

BaaS fits some situations much better than others -- recognizing which one you're in matters more than picking a specific product by reputation.

Good fit: prototyping and MVPs
Good fit: small-to-medium applications
Good fit: teams without a dedicated backend engineer
Weaker fit: highly custom business logic that doesn't map onto generic building blocks
Weaker fit: unusual data access patterns the platform wasn't designed around
Weaker fit: a hard requirement for full control over underlying infrastructure

BaaS: Backend-as-a-Service: a platform category providing ready-made backend building blocks (auth, database, storage, realtime, functions) that you connect to, instead of infrastructure you build and operate yourself.

text

BAAS MENTAL MODEL
-----------------
                 +------------------------+
                 |          BaaS           |
   Frontend ---->|  Auth   |  Database      |
                 |  Storage |  Realtime     |
                 +------------------------+

Connect it to a real scenario

Start with an honest inventory of what your backend actually needs -- login, structured data, file upload, and live updates are common needs BaaS usually covers well.

Signup/login and session management
Storing and querying structured data
Letting users upload and retrieve files
Pushing realtime updates to connected clients

Highly custom logic -- a proprietary algorithm, an unusual legacy integration -- still needs somewhere to live: BaaS-hosted functions, or a separate custom backend.

A common middle path is hybrid: BaaS for generic pieces, custom backend code for the genuinely unique parts -- and this choice can change later as needs become clearer.

BaaS provides ready-made backend building blocks -- auth, database, storage, realtime -- so common backend needs don't have to be built from scratch.
BaaS tends to fit prototyping, small-to-medium apps, and teams without dedicated backend engineers best.
Highly custom business logic, unusual data patterns, or a need for full infrastructure control are signs a project may need more than pure BaaS.

Try the working example

javascript

function suggestBackendApproach(project) {
  const { needsAuth, needsDatabase, needsRealtime, hasCustomComplexBusinessLogic, hasDedicatedBackendTeam } = project;

  if (hasCustomComplexBusinessLogic && hasDedicatedBackendTeam) {
    return "custom backend";
  }
  if (needsAuth || needsDatabase || needsRealtime) {
    return "BaaS";
  }
  return "custom backend";
}

const projects = [
  { label: "Weekend prototype with login and a database", needsAuth: true, needsDatabase: true, needsRealtime: false, hasCustomComplexBusinessLogic: false, hasDedicatedBackendTeam: false },
  { label: "Fintech platform with complex settlement logic and a backend team", needsAuth: true, needsDatabase: true, needsRealtime: false, hasCustomComplexBusinessLogic: true, hasDedicatedBackendTeam: true },
];

for (const p of projects) {
  console.log(`${p.label} -> ${suggestBackendApproach(p)}`);
}

You should see

Weekend prototype with login and a database -> BaaS
Fintech platform with complex settlement logic and a backend team -> custom backend

5-minute try-it

List the backend needs of an app idea you have. Which needs would a BaaS platform likely cover directly, and which would need custom logic layered on top?

One important caution

Assuming BaaS means no backend code ever -- custom business logic still needs somewhere to live, often as functions the BaaS platform hosts.

Treating the BaaS-vs-custom-backend choice as permanent and all-or-nothing, when hybrid approaches are common and switching later is normal.

Wikipedia: Mobile backend as a service — Cloud Providers & Platforms