Built with Base44?

Your Base44 app works when you use it. It breaks when your customers do.

Base44 goes further than most AI builders: it does not just write your frontend, it provisions the backend too. Database, auth, file storage, payments and analytics are all built in, running on Base44's infrastructure and reached through their SDK. That is why the build was so fast. It is also why production feels different: the backend is not code you can read, it is a service you configure, and the configuration a fast build leaves behind is exactly what breaks when real customers arrive.

What actually breaks

• Entity permissions that let any user read the lotBase44's database is a set of entities with an auto-generated API, and the SDK queries it straight from the browser. Access is controlled by row level and field level rules on each entity. During the build, permissive rules keep everything working; ship them unchanged and any signed-in user can query other customers' records, with full MongoDB-style filters, from dev tools. Base44 runs its own Security Center that scans apps for exactly this, because misconfigured rules are common enough to need a scanner.
• Your login page belongs to the platformAuthentication is Base44's service: registration, sessions and SSO run on their platform, not in your code. That cuts both ways. In July 2025, Wiz Research found that anyone could create a verified account on a private, SSO-restricted Base44 app using only its public app_id, through unauthenticated register and OTP endpoints. Wix patched it within a day, to their credit. But the lesson stands: when the platform owns auth, its vulnerabilities are yours, and you cannot patch them yourself.
• The GitHub repo is not an exitThe GitHub integration, on the Builder plan and up, syncs your code to a repository you own: the React frontend and your backend functions as TypeScript source. What it cannot include is the platform they call into. Every real operation, reading data, saving a record, logging a user in, goes through the Base44 SDK to their hosted service, and entities never sync at all. Deploy the repository elsewhere and the screens render over nothing. Your data comes out as file exports, not a database another backend can adopt.
• The published app is not the app you testedIn the editor you are the owner: signed in, admin role, every rule satisfied. Your customers arrive at the published URL signed out, with no role, on a different domain. Entity rules you never exercised now decide what they can see, and features that quietly depended on your session return nothing. Works in the editor, broken on the live URL is a constant refrain in Base44 community threads, and the cause is nearly always this gap between your context and theirs.
• Backend functions that opt out of your rulesBackend functions run on Deno with, in Base44's own words, full access to your app's data and integrations. Called through the SDK, they carry the signed-in user's credentials and entity rules still apply. Two doors bypass that: asServiceRole, which switches entity rules off for whatever the function does, and direct HTTP calls, where the docs are blunt that there is no authenticated user context. The AI reaches for both to make features work; it rarely adds the caller check that has to replace the rules it turned off.
• Payments pass in the sandbox and drift in productionBase44's Stripe integration starts every app in a test environment, and the sandbox does prove checkout works. What it cannot prove is the billing lifecycle: the renewal that fails on an expired card, the customer who cancels mid-cycle, the refund that should revoke access. Whether access actually ends is app logic the AI wrote against the happy path. This one surfaces weeks after launch, as customers quietly keep using a product they have stopped paying for.

How I work in a Base44 project

On the Builder plan and above, Base44 syncs your app two ways with a GitHub repository you own: my commits flow back into the builder, and the builder stays yours after the sprint. The repository holds more than screens; backend functions live in its functions directory as TypeScript files, so I fix server logic there like any other code. Entities are the exception: their schemas and security rules stay managed inside Base44, so those I change in the platform's own tooling and check against the live app, Security Center included. While I am committing, hold off on prompting the builder; the two-way sync means an AI rewrite can land on top of a fix mid-sprint. Send change requests to me instead and I will fold them in.

What “done” looks like

We agree one of these in writing before you pay anything. If it passes, the sprint passed. If it doesn't, you get a full refund and keep the work.

• ✓Signed in to a second customer's account, I fire entity queries from the browser console with the widest MongoDB-style filters the SDK accepts; the only rows that come back are that customer's own, and you watch the query run at handover.
• ✓On the published domain, signed out, every page and entity you believe is behind login actually demands it. The editor never shows you this; the check has to run on the live URL where your customers land.
• ✓Every backend function the client can reach either inherits the caller's entity permissions through the SDK or, where it uses asServiceRole, verifies the caller itself; I invoke each one as the wrong user and over bare HTTP to prove it.
• ✓A live-mode Stripe subscription that cancels or fails renewal loses access with no manual step; one real payment run through the full cycle, cancellation included, demonstrates it before I leave.

Other things that block launches

• Your Lovable app works in the preview. It breaks in production.
• Stripe took the money. Your customer got nothing.
• Your Bolt.new app runs fine in the preview. The published version doesn't.
• Your Replit app works in the workspace. The published version doesn't.
• Your v0 app looks ready to ship. The part that breaks is the part you can't see.
• Your Cursor app runs on your machine. That is the only place it has ever been tested.
• Your customers can see each other's data. It is never just the one screen you found.
• Users can't sign in. It worked every time you tested it.
• It runs on your laptop. It will not deploy anywhere else.
• Your AI feature is impressive when it works. You can't put it in front of a customer.
• The full The Launch-Blocker Sprint