Cross-platform SaaS with one backend - web, mobile, and browser extension from a monorepo

If you are planning a cross-platform SaaS - a product that lives as a website, a phone app, and maybe a browser extension - the painful question shows up early: do you run three backends, or one?

Most founders start with a web app, then bolt on mobile, then “we’ll add an extension later.” Each surface quietly grows its own auth, its own API quirks, and its own half-synced billing rules. Six months in, you are debugging three session bugs for one product.

This guide explains the architecture, what to share vs keep separate, how session and billing stay consistent, and when separate repos still make sense.

What is a cross-platform SaaS monorepo?

A cross-platform SaaS monorepo is a single repository that contains multiple deployable apps (web, mobile, extension) plus shared packages for the API, database, auth, and billing. Clients talk to the same backend. You change a plan limit or permission once; every surface respects it.

It is not “one React Native app wrapped for the web.” It is not three unrelated repos that happen to share a brand. The monorepo is the structure; the single backend is the contract.

Why founders end up with three backends (and regret it)

The default path looks responsible:

1. Ship a Next.js SaaS with auth and Stripe.
2. Hire for mobile - new Expo app, new API routes “just for the app.”
3. Add an extension - another auth dance, another set of fetch helpers.

Each step feels small. The cost compounds:

You did not choose complexity. You postponed a architecture decision until it became expensive.

The better model: one backend, three thin clients

Think of your product as a hub and spokes:

                    ┌─────────────┐
                    │  packages/  │
                    │  api · auth │
                    │  db · bill  │
                    └──────┬──────┘
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
      apps/web        apps/mobile     apps/extension
      (Next.js)         (Expo)            (WXT)

• Hub: Hono API, PostgreSQL + Drizzle, Better Auth, billing providers, emails, storage.
• Spokes: UI and platform glue only - navigation, store packaging, content scripts, push notifications.

The mental model that keeps teams sane: business rules live in packages; pixels live in apps.

What you should share (and what you should not)

Sharing everything is how monorepos turn into spaghetti. Be intentional.

Share these packages

In TurboStarter this maps to packages like @workspace/api, @workspace/auth, @workspace/db, and @workspace/billing - see the project structure docs.

Keep these platform-specific

If a function does not care whether the caller is iOS or Chrome, it probably belongs in a package.

How one API serves web, mobile, and extension

TurboStarter’s API is a Hono app living in packages/api. By default it mounts on the Next.js web app as a catch-all route:

import { handle } from "hono/vercel";

import { appRouter } from "@workspace/api";

const handler = handle(appRouter);

export {
  handler as GET,
  handler as POST,
  handler as OPTIONS,
  handler as PUT,
  handler as PATCH,
  handler as DELETE,
  handler as HEAD,
};

Mobile and extension do not reinvent that server. They call the same deployed API with a typed Hono RPC client and React Query for caching. Docs: web API, mobile API, extension API.

Auth that feels like one product

• Web owns the primary login UI (email, OAuth, MFA, passkeys).
• Mobile uses the same Better Auth configuration against the shared server.
• Extension typically shares the web session instead of inventing a second login - the same pattern Notion and Google Workspace use. Sign in once on the site; the extension reuses the cookie/session for your domain. Details: extension session docs.

That single decision removes a whole class of “why am I logged in here but not there?” support tickets.

Billing that does not fork

Plan checks and entitlement helpers live next to the API and billing packages. Web checkout, mobile paywalls, and extension feature gates read the same customer and plan state. You still use platform-native purchase UX where stores require it - but the source of truth for “what can this account do?” stays on your backend.

Monorepo vs separate repos vs web-only starter

ShipFast-style kits optimize for the first row. Makerkit and supastarter document monorepos well for web scale (marketing app + SaaS app, shared packages). Very few boilerplates ship Expo + WXT clients on the same auth and API as a first-class story - that gap is exactly where TurboStarter sits. For kit comparisons, see best SaaS starter kit 2026 and TurboStarter vs ShipFast.

A practical build order (so you do not overbuild)

You do not need all three clients on day one. You need the hub ready so spokes are cheap later.

1. Stand up the monorepo and shared packages - db, auth, api, billing.
2. Ship web - marketing, dashboard, checkout, admin.
3. Point mobile at the same API when App Store demand is real.
4. Add the extension when the product needs “lives in the browser” workflows (clippers, overlays, side panels).

This order keeps cashflow and learning tight. The architecture still assumes multi-platform from week one, even if apps/mobile sits quiet for a quarter.

Estimated effort once the hub exists (solo or small team, rough ranges):

Numbers are planning ranges, not guarantees - your product surface and store review times vary. The relative gap is the point: the second and third clients get cheaper when the first client did not invent a private backend.

Common mistakes (skip these)

Duplicating “just a little” business logic in the client. Feature flags evaluated only in the React Native app will disagree with the web dashboard. Gate on the server.

Treating the extension like a mini website. Content scripts run in hostile pages. Keep secrets and privileged actions in the background + your API. See extension security.

Sharing UI components blindly across React DOM and React Native. Share types, hooks, and domain logic first. Share pixels only when the abstraction is proven (or use separate UI packages per platform, which TurboStarter does).

One giant packages/utils dumping ground. Prefer named packages (auth, billing, db) so AI agents and humans can find the door.

Forcing mobile on every SaaS. If your buyers live in a browser and never open an app, ship web well. Keep the monorepo ready; do not invent App Store work for vanity.

How TurboStarter implements this today

TurboStarter is a production SaaS starter kit built as a Turborepo monorepo:

Out of the box you get organizations, RBAC, admin tooling, emails, and marketing patterns - the boring 80% of SaaS - already wired for multi-client use. Stack details: best SaaS stack 2026. Mobile path: Expo guide for web developers. Monorepo fundamentals: Turborepo guide.

Frequently asked questions

The takeaway

Cross-platform SaaS succeeds when your architecture matches how customers experience the product: one account, one plan, one source of truth - on every device.

Separate backends feel faster for the second weekend. They tax every weekend after that. A monorepo with one backend and thin clients keeps your roadmap about features, not about re-syncing three half-true systems.

If you want that foundation ready - Next.js web, Expo mobile, WXT extension, Hono API, Better Auth, billing, orgs, and admin - start with TurboStarter, read the docs, and ship the spoke you need next without rebuilding the hub.