SaaS founders

Can You Build a SaaS on Base44?

OffRamp · November 7, 2026 · 8 min read

Short answer: yes — for the MVP. No — not as the permanent home for a real multi-tenant product. Base44 builds a working SaaS shell — auth, database, Stripe, hosting — in the time a custom team spends scaffolding. But SaaS founders are a distinct buyer class with a distinct breaking point: multi-tenant isolation. Base44 has no tenant object, the AI sets your row-level security rules, and a field report published on Base44's own file host documents the multi-tenant limits from a real build. The honest answer is "Base44 now, custom later" — and the founders who treat it that way ship faster than the ones who treat it as a foundation.

Start your free analysis Where it works

The part that works

Where SaaS on Base44 works

Start with the honest part, because it is genuinely good. Base44 turns a plain-language description into a full-stack web app: database, authentication, backend functions, hosting, and Stripe payments arrive together, without wiring. For a SaaS founder, that means a clickable, data-backed product with logins and a pricing page in days — sometimes in a single session. One creator built a working DocuSign-style tool with file uploads, a recipient system, signature fields, email delivery, a dashboard, and a Stripe-connected pricing page in about 30 minutes on a $16-a-month plan. Some features were broken on the first build and needed a few rounds of fixing. Most of it worked.

That is the use case Base44 is built for: the MVP and the design-partner stage. You need a real screen, a real database writing real rows, and a login so five design partners can try it. Base44 gets you there in an afternoon, and every dollar you did not spend on a throwaway prototype is a dollar left for the build that counts. Single-tenant tools are the sweet spot — an internal tool for one business, a client portal, a simple CRM, a member dashboard. One tenant means the isolation problem this page is about barely exists.

The same logic applies to agencies shipping client apps: a working product in front of a paying client this week beats a perfect architecture six months from now. The line is sharp because of one fact: when you export a Base44 app, you get the React frontend, not the running product. The database, authentication, and backend logic keep calling Base44's servers through its SDK. So "you own your code" is true of the screens and false of the system. That gap is manageable while you are validating. It becomes the whole problem the moment strangers' private data depends on it.

The breaking point

Where it breaks: tenant isolation is manual, not automatic

A SaaS is not one app with many users. It is many customers' private data sharing one database, and the one rule that matters is that Customer A never sees Customer B's records. On a standard stack that rule lives in the database: Postgres row-level security, enforced server-side, with a service key that genuinely bypasses it for trusted code. On Base44 the rule exists — but you build it yourself, entity by entity, and the platform does not check your work.

First, there is no tenant object. Base44 has no tenant or organization object for your app's users; the documented pattern is to model a Company or Team entity yourself and link it to the built-in User entity. The multi-tenant setup Base44 documents is an Entity-User Field Comparison rule matching a company_id on each record to the same property on the signed-in user — "each person only sees records that belong to their company." The platform does not apply that rule for you: every entity holding tenant data needs its own rule, and a rule that lets any signed-in user read every row is a cross-tenant leak, not a configuration quibble. Base44's own CLI reference warns that if no RLS is defined, all records are accessible to all users — and the AI sets data permissions automatically as it builds each entity, which means the rules exist because a prompt wrote them, and they can be too broad.

Second, the field that decides access must not be writable by the user it describes. Base44 lets you add custom fields to the User entity and use them in rules — and by default, app users can change the custom fields on their own profile. If your isolation rule trusts a field the user can edit, the user can set it to another company's value and get that company's access. Base44 added a security scan in October 2026 that flags exactly this: custom User fields that your rules rely on but app users can change. Run it. Then test with two accounts — Account A in tenant X should never see anything from tenant Y, ever — and rerun the test after every edit that touches a list query or an access rule.

Third, the scale ceilings arrive quietly. Base44 caps list and filter calls at 5,000 records per request, so large reads need cursor pagination. There are no transactions across entities, so a multi-entity update can fail halfway and leave inconsistent state. There are no unique constraints, so duplicate records are a bug you prevent in code, not in the database. And rate limits hit at unpredictable thresholds on burst writes — a SaaS with a busy hour is exactly the workload that finds them. None of these is fatal for a design-partner product. Left unchecked, all of them are fatal at scale.

The gotcha, documented by a real build

The service-role gotcha: what Base44's own field report found

The sharpest evidence for the MVP-vs-scale split comes from Base44's own file host. "Base44 Platform Limitations: A Field Report" — published on media.base44.com — documents what a team building Telos, a multi-tenant coaching platform, actually hit. Each coach gets a workspace and owns brands, contacts, appointments, and other private data. Private data must never leak between coaches, even when they share the same workspace. Building that on Base44, the team hit a series of platform-level limitations that would not exist with a standard backend setup.

The first finding is the one that matters most: asServiceRole did not actually bypass RLS. Base44's service role is the pattern for operations that run without a real authenticated user — public functions, system jobs. The docs and the SDK's framing implied it bypasses row-level security. It did not. Base44 support confirmed to the team that asServiceRole impersonates a synthetic admin user with no workspace ID, and RLS rules are still evaluated against that synthetic identity. Worse, the synthetic service user presents as role: admin — indistinguishable in RLS evaluation from a real human admin — so there is no service-role flag, no machine identity, and no bypass token visible to the rule engine. For a platform where coaches are admins, that forces parallel workarounds for every public function.

Two more findings compound it. When one backend function calls another through the service role, the inner function receives a raw HTTP request with no forwarded auth headers — chained calls strip auth context. And RLS rules use template variables like {{user.id}}, but custom User fields require the user.data.<field> syntax: using {{user.workspace_id}} for a custom workspace field silently resolves to undefined and breaks every workspace check. The team also found deploys unreliable — edits to function source files do not always propagate to the runtime, and deploys can time out or silently fail — and ended up building parallel "snapshot" entities with deliberately open read rules just to serve public data, a workaround that cannot be used for private entities like contacts, where any public-readable mirror would be a privacy disaster.

One honest caveat, because this matters: Base44's current documentation — read by independent reviewers in October 2026 — now states that asServiceRole "bypasses both RLS and FLS entirely" and that your function is responsible for any access checks it needs. The field report and the current docs do not agree, and the report may predate a platform change. Do not take either side on faith. The practical rule is the same either way: service-role code must re-check tenant ID manually on every query, because the entity rules do not apply to it — and you must test the behavior on your own app, in preview, as a user from each tenant, before your first paying customer signs up. A SaaS needs five disciplines that are not the platform default, and skipping any one ships a leak.

The money layer

Billing: the easy slice works, the edges don't

Base44 connects to Stripe and handles flat-rate or simple tiered subscriptions out of the box, and for many SaaS products that is the whole billing story. If your pricing is "pay a predictable amount to use the product," stay on Base44 and ship. Our Stripe payments guide covers what migrates with you when you eventually leave — the money data lives in Stripe, the wiring lives in Base44.

The wall is in the billing edges. Metered usage, per-seat proration, and mid-cycle plan changes have no native support and must be coded in backend functions. Base44 has no native concept of a usage meter: if you charge per API call, per generated report, per gigabyte stored, or per seat-hour, nothing in the platform counts that for you. If billing is the product — your entire value proposition is sophisticated usage metering, a complex marketplace take-rate, or billing-grade financial auditability from day one — then Base44 is fighting your core requirement, and you should weigh a move before you build the billing layer twice.

And bill the workspace, not the user. A user can belong to multiple workspaces, so create a subscriptions collection keyed by workspace_id, with the Stripe customer and subscription IDs on it. Do not create one subscription record per user: you will end up with orphan customers and double-billing the moment a user joins a second workspace. This is the same class of mistake as the tenant-isolation one — the platform gives you the pieces, and the discipline that makes them correct is yours.

The meter at scale

Credit burn at scale: two meters, one allowance

The other way a SaaS outgrows Base44 is the meter — and it is unusual, because there are two of them. Message credits pay for talking to the builder AI. Integration credits pay for what your published app does at runtime: sending an email, generating an image, running an LLM call, answering a question through an in-app agent, firing an automation. Your building and your users' activity draw from the same monthly allowance, it does not roll over, and when the integration balance hits zero your live app starts failing for the people using it.

As of November 2026, Base44's own pricing page lists: free at $0 with 25 message credits and 100 integration credits a month (up to 5 apps); Starter at $16 a month billed annually with 100 message and 2,000 integration credits; Builder at $40 with 250 and 10,000; Pro at $80 with 500 and 20,000; Elite at $160 with 1,200 and 50,000. Annual billing saves 20% against monthly. Check base44.com/pricing before you commit — prices change often, and the monthly-billed equivalents run higher than the annual figures shown. The structure is the stable part, not the numbers.

Do the math on your own usage before you promise a launch date. A SaaS whose users trigger automations, AI features, and emails all day burns integration credits in proportion to its success — the more customers you win, the faster the meter runs, and the bill for the next tier is the price of the growth you just earned. That is not a reason to avoid Base44 for the MVP. It is a reason to know, before you have fifty paying customers, what the meter costs at five hundred.

The exit, planned early

What scaling off looks like

The decision is not "Base44 vs custom." It is "Base44 now, custom later." The teams who treat Base44 as a permanent foundation get bitten. The teams who treat it as a runway to validate, then migrate, ship faster than the competition — because the MVP taught them what to build before they paid to build it properly.

Scaling off means rebuilding on infrastructure you own: your Supabase database, your Vercel hosting, your GitHub repo. On that stack the multi-tenant rule lives where it belongs — Postgres row-level security, enforced server-side, with a service key that genuinely bypasses it for trusted code — and the billing layer is yours to shape, metered or flat, per seat or per workspace. The rebuild is a real project: tables leave Base44 one at a time as CSV exports, users reset their passwords because password hashes cannot be exported, and the Stripe subscriptions move by reconnecting the same Stripe account. Our user-accounts guide walks through what moves and what does not, and our database guide covers why there is no back door to your data.

The right time to plan the move is before you need it — while the app is still small enough that the rebuild is weeks, not quarters. If you are already feeling the ceiling — the isolation rules are getting fragile, the credit bill is tracking your growth, the billing edges need custom functions — that is the signal, not a failure. It means the MVP did its job. The founders who win on Base44 are the ones who know, from day one, that the platform is the runway and not the destination.