What "built-in backend" means on Lovable, Bolt, Replit, v0 and Base44, and what it leaves out

A built-in backend is the database, sign-in, file storage and server functions that a vibe-coding platform hosts for the apps built on it, so that a prompt can add a table or a login without you opening an account anywhere else. It is the reason a non-developer can get a working app in an afternoon, and it is the reason the app stops at a very particular place.

That place is the subject of this post. As of 27 October 2026, Lovable, Bolt, Replit and Base44 each ship a built-in backend, and v0 wires one together from Vercel's marketplace. Every one of them covers a database, a login and, on paid plans, a way to take money. None of them documents teams, roles, invitations, plan limits, seats or credits for the people using your app. The gap is the same on all five, and it is worth seeing in one place, because the vendor pages about these builders go stale within a quarter and most of them still describe last year's builder.

Everything below was read from the builders' own documentation on 27 October 2026, and says so where a claim is a vendor's rather than a builder's. If you are reading this months later, check the dates against the changelogs before you lean on a row.

Why built-in backends exist

They exist because the alternative is a terminal. A Hacker News commenter put it in one sentence in August 2026, explaining why non-technical builders pick Lovable over Claude Code: "With CC you still have to host it somewhere. On Vercel, get a DB somewhere or tell it to use SQLite, which no one knows what that is. You have to install it and use a terminal which no one knows how to do."

The first generation of builders did not solve this. They generated a React app in the browser and left the data to Supabase, which a builder had to sign up for, configure and secure. Another commenter described the result in December 2025: Lovable "uses Supabase by default and basically generates React SPA's with no true backend. But random people won't understand this distinction and will want to create full real apps." The 2025 scan that became CVE-2025-48757 found 170 of 1,645 sampled Lovable apps with database tables any visitor could read, which is what "no true backend" looks like from outside.

So the builders absorbed the backend. Lovable launched Lovable Cloud in September 2025, Bolt launched Bolt Cloud the same week, Replit already had its database and added Replit Auth, Base44 was built around its own data and identity layer from the start. The business reason sits beside the product reason: a backend the builder hosts is usage the builder bills. Lovable draws Cloud usage from the same credit balance as building, Replit bills deployments and the production database by usage, and Base44's founder told Calcalist in August 2026 the company expects gross margin to move from near break-even to about 60% as that usage matures.

What each one includes

The table is the summary; the paragraphs are what the docs actually say. "End users" means the people who use your app, as distinct from you and your collaborators inside the builder.

Lovable Cloud. The docs describe "a managed PostgreSQL database, login, and file storage", with realtime and functions, and say most projects never need a separate Supabase account. The Users view is a searchable list with sign-up and last sign-in times and the methods each person used; the sign-in page mentions no roles, teams, workspaces or invitations for end users. Secrets are write-only ("its value can never be viewed again in Lovable, only replaced or deleted") and are injected into edge functions and server-side integrations at runtime. Payments arrived on 24 April 2026 through Paddle or your own Stripe, on Pro and up, with one active subscription per user by default and one provider per project; a project with payments on cannot be forked. Email is not listed as part of Cloud; the docs point to a separate guide on sending from your own domain. Two limits worth knowing before you commit: a database export is allowed once every 24 hours, and removing Cloud "permanently deletes the database, its backups, your app's user accounts, and the files in storage". New apps since 13 May 2026 are TanStack Start apps rendered on the server; older ones are React with Vite.

Bolt Cloud. Bolt's docs describe a database with email and Google sign-in, storage, server functions and Stripe, a security audit you can run from the Publish menu, and a Site URL plus a redirect allow list that Bolt usually updates when you publish. Supabase's own post of 30 September 2025 says Bolt Cloud backends run on Supabase. Bolt hosting is the default publish target; the Netlify alternative is for static sites, and Bolt's own page says Netlify "can't host a database or a traditional backend". Bolt's docs mention no roles, teams or permissions for end users.

Replit. The strongest technical fit of the five, because a Replit project is a real Linux workspace with a shell, so anything that installs with npm installs. Replit Auth is "Replit-branded sign-in with zero setup": your users sign in with a Replit account, through Replit's shared OAuth apps, in a single environment. Clerk Auth is the other first-party option, which the docs recommend for "branded apps, professional and commercial products": a Clerk tenant of your app's own, separate development and production environments, Google, GitHub, Apple and X with your own OAuth credentials in production, and a Users tab. The same page lists what Clerk Auth does not include today, and the first item is "Organization tenants, Clerk's organization and team-membership features". Roles and permissions for your users are not mentioned on either page. Secrets are set in the Tools pane and arrive as environment variables, with production values set separately under Publishing. After the July 2025 incident in which the agent deleted a customer's production database during a code freeze, Replit rolled out automatic separation of development and production databases.

v0. v0 generates Next.js with React, TypeScript, Tailwind and shadcn, and has no backend of its own. Databases come from the Vercel Marketplace inside the chat; one-click integrations for Clerk, Auth0, Resend and others arrived in September 2026, and v0 loads a provider's published skills automatically when its integration is installed, which is how it knows the provider's patterns. Vercel bought Better Auth on 7 July 2026, so the likeliest sign-in an agent on v0 reaches for is Vercel's own. Environment variables live in the Vercel project and reach previews, which run the full application. Publishing is one click to Vercel.

Base44. "Base44 apps are standard React apps built with Vite", with entities/ holding a JSON schema per entity and functions/ holding one TypeScript file per backend function. With the two-way GitHub integration, entities are managed in Base44 and are not included in your local repository. Sign-in is configured in base44/auth/config.jsonc: email and password, Google, Microsoft, Facebook and Apple, or SSO through Google, Microsoft, GitHub, Okta or a custom provider, with SSO and social login mutually exclusive. No roles, teams or permissions for end users appear on that page. In July 2025 Wiz found that Base44's registration and OTP endpoints accepted requests without authentication, so anyone holding an app's public id could create a verified account on a private app; Wix fixed it within about a day and found no abuse.

Google AI Studio's build mode, for completeness: its agent provisions Firebase Authentication and Firestore from the prompt, so it is a sixth built-in backend in everything but name, with Firebase's rules model underneath.

The line every one of them stops at

Read the right-hand column again. Five builders, read on the same day, and the same four absences: teams, roles, plan limits, credits. It is not an oversight on one of them. It is where "an app" stops and "a product" begins, and it is the line a built-in backend was never asked to cross.

Here is what the absence means in practice, in the order a stranger meets it:

• The second person from the same company. The built-in backend gives every person an account. It does not give a company one. Two colleagues sign up separately, and nothing in the backend knows they belong together, so there is nothing for a prompt to build on when you ask for "teams". What the agent builds instead is a teams table and a role column checked on one page, which is the bug every audit of a vibe-coded app finds. Teams, invites and admin versus member is what the layer looks like when it exists.
• The plan that has to change what the app does. Lovable's built-in payments give a user one active subscription. Bolt's and Replit's Stripe connectors take a payment. None of them connects the payment to a feature, a seat count or a limit, so the connection is code the agent writes, usually in the browser, where a February 2026 audit found "a live marketplace with real Stripe payments where any logged-in user could grant themselves admin". Paid plans that actually gate features is the other half.
• The email that arrives. Every built-in sign-in sends confirmation and reset emails, and every one sends them from a development sender until you connect a domain. Supabase's default sender delivers only to your project's team, at two messages an hour, by its own docs.
• The credit that runs out. An AI feature needs a balance someone can spend down and a hard stop when it is gone. Nothing in the five backends holds one, which is why "development endpoints still in production that let anyone mark themselves as a paid user and give themselves unlimited credits" was a finding rather than a surprise.

Where the built-in backend wins

For a single-user app, a prototype, an internal tool or a weekend project, the built-in backend is the right choice and nothing external comes close. It is zero configuration inside the builder, it is paid for from the same balance you are already paying, and the security checks (Lovable's Quick scan runs on every publish; Bolt's audit is a free button in the Publish menu) cost nothing extra. Replit Auth is "zero-setup" in the literal sense: ask the agent and the login page exists.

There are specific things the built-ins have that BuildBase does not, or has only with more setup. Lovable's sign-in ships SAML SSO and OIDC of its own, where ours runs through your own WorkOS account on the Enterprise plan, so an app whose buyer signs in with Okta and wants one vendor is better served there. Lovable's Paddle option makes someone else the merchant of record, which handles the tax side; our billing is Stripe, bring your own, and the tax side is yours. Base44's entities are a data model you never have to write a migration for. Replit's Clerk Auth gives a commercial app a branded tenant with separate development and production environments, provisioned without a Clerk account. If any of those is the thing you need, the built-in is the pick, and this post is not trying to talk you out of it.

When the built-in backend is the wrong choice

The moment two people share an account, the moment a plan has to change what the app does, and the moment you need to leave.

The first two are the gap above. The third is about the exits, which are real but narrower than the pitch. Lovable Cloud exports once every 24 hours, removing Cloud deletes your app's user accounts with the database, and the docs say moving to your own Supabase "isn't a one-step switch": you export and restore the database, move storage files and code, and set up auth, secrets and external services again. Base44's entity definitions stay in Base44 even with GitHub sync on. Bolt's one-click alternative host is static. Replit's data lives in Replit's database until you export it. None of this is hidden, but it is the kind of thing people discover on the day they want to leave, and a commenter on Hacker News in August 2026 described a client's Lovable backend as "completely inaccessible except through the lovable interface" (Lovable's changelog has since added exports and a way to create your own Supabase project, so check the current docs before repeating that).

There is a fourth moment, quieter than the others: when the agent's own tables go wrong. The built-in backend hosts the database; it does not write your row rules. UpGuard's scan in September 2026 found 16,326 Supabase databases with a publicly readable users table, and noted that tables created through the API, which is how coding agents work, "do not enable RLS by default". Lovable's Quick scan checks that rules exist, not that they are right, which is the distinction the researcher behind CVE-2025-48757 drew about Lovable's 2025 scan too. A built-in backend makes the database easy to create and leaves its safety to the same prompt that created it.

Three questions to ask before you lean on one

The table above is what the docs say today. These three questions decide whether a built-in backend is still the right call in a year, and each has a different answer per builder, so ask them before the first stranger signs up rather than on the day you want to move.

Can I get the database out, and how often? Lovable: an export once every 24 hours, and a documented path to your own Supabase project that its docs call "not a one-step switch". Base44: the code syncs to GitHub both ways, the entity definitions do not; they are managed in Base44. Bolt and Replit: the code is in GitHub as soon as you connect it (Bolt polls the repository for changes about every 30 seconds; Replit's Git tool pushes), and the data stays in the builder's database until you export it from there. v0: nothing to export from v0, because the database was never v0's; it is a Neon or Supabase project in your Vercel account.

Do my app's users come with me? This is the question nobody asks. On Lovable, removing Cloud deletes "your app's user accounts" along with the database, so the accounts live and die with the backend. On Base44 the accounts belong to Base44's identity layer, which the GitHub sync does not carry. On Bolt Cloud and Replit Auth the users are rows in the builder's sign-in system; Replit's docs describe Replit Auth as Replit-branded with a single environment, and Clerk as the white-label route, which is also the portable one. If the people who signed up are the asset, where their accounts live is the decision, and it is made on the day sign-in is switched on.

What does the security scan actually check? Lovable's Quick scan runs on every publish and checks that row rules exist; the researcher behind CVE-2025-48757 drew the line between "a policy exists" and "the policy is right" about Lovable's 2025 scan, and it still holds. Bolt's audit goes wider than most: its help page lists checks on whether protected pages require an account, whether a user can change a price or skip a step, whether keys reach the browser, and a database review that flags "a permission rule that allows anyone to read a table". On Replit the database is reached from your own server code, so the equivalent question is whether every route checks who is asking, and no scanner answers it. None of them knows which workspace a row belongs to, so a rule that says "any signed-in user can read every row" is a rule, and it passes.

The honest summary: the built-in backend is the easiest backend to start and the hardest to leave, and nothing about that is hidden. It is simply not on the pricing page.

How BuildBase sits beside it

BuildBase is not a database, and the rule every agent gets is "do not use BuildBase as the primary database; pair it with Supabase or Postgres". So the shape, on every builder, is the same: the built-in backend keeps your tables, your files and your functions, and BuildBase holds the parts in the right-hand column (the workspace a customer belongs to, the role each member has, the plan the workspace pays for, the credits it may spend, the email that goes out when a card fails), reached through hooks in the app and a server SDK in your functions.

Each builder has a guide for the join, with what was tested and what was not: Lovable (new apps are TanStack Start, which can hold the sign-in routes; older ones are Vite and need a server first), v0 (Next.js, where npx buildbase init writes the files), and the Claude Code and Cursor route for anyone with a terminal. One honest wrinkle applies wherever Supabase holds the data: its row-level security cannot verify a BuildBase session directly, so data either goes through server routes that check the session, or your server mints a Supabase-shaped token; the Lovable guide has both.

The explainer underneath all of this is what a SaaS backend is, and which half of it is your product: the account model (who the user is, which customer they belong to, what they may do, what they owe) is the half the built-in backends leave to you, and the launch checklist is the twenty-item version of what that half contains.