Is my Base44 app actually ready for real users?

Sixty seconds, no AI. Most people are fixed by one of these and never need the prompt below.

1. 1

   Open your app in a private window, signed out. Two failures hide here. If you see nothing at all, your app is login-gated and invisible to search — Base44's docs: "Pages that require a login are always excluded from search engine indexing." If you see data you did not expect to be public, that is the other failure. The full check is here.

2. 2

   Make a second account on your own app and look at the first account's data. This is the single test that catches the problem that actually ends businesses, and it takes two minutes. Two builders reported tenant-isolation failures in the Base44 Discord in one week.

3. 3

   Sit on your busiest screen for sixty seconds without touching anything, with the browser's network tab open. Every request that fires while you are idle is one you pay for on every user's session. That is where 429s come from. Rate limits, with the real numbers.

4. 4

   Publish, then load the live URL in a fresh private window — not the editor preview. Confirm the change you just made is actually there. A builder lost 16 hours in September 2026 to a publish that reported success while "built JS/CSS assets aren't pushed to the CDN — every asset hash 404s on the live site".

5. 5

   Load your domain with and without www. Both should resolve, one should redirect to the other, and the certificate should be valid for the domain you typed. Remove any AAAA records — Base44 only supports IPv4.

6. 6

   Count your pages and read the thinnest one as a stranger. A handful of half-finished screens is what fails an AdSense review, an app store submission and a first customer, for the same underlying reason.

7. 7

   Check status.base44.com before concluding any of the above is your fault.

Base44 makes the first 80% fast and leaves the last 20% almost entirely to you — and the last 20% is all of it invisible until someone who is not you arrives.

The pattern is consistent. Everything you test, you test as yourself: signed in, on your own account, in the editor preview, with three records and no concurrency. Every one of the six failures below only appears when that stops being true.

Open data. Nothing warns you when an entity is created without an access rule, and an entity with no rule returns every record to anyone. You will never see this as the only user.

The auth wall. If the whole app needs a login, crawlers see nothing and your marketing pages do not exist as far as search is concerned. Correct behaviour, wrong outcome.

Request volume. Limits are per person. With one user a polling loop is invisible; with a hundred it is a 429. And the three entity write limits do not rise with your plan, so you cannot buy your way out of a bulk import.

Publish state. The editor preview and the live site are different things and can disagree. Builders report published changes not appearing, publish buttons that grey out, and assets that 404 after a successful publish.

Domain and SSL. Auto-DNS can overwrite existing records; registrar forwarding silently creates an A record that fights it; some TLDs never get www SSL; and ICANN will suspend a domain about two weeks in if you never clicked the verification email.

Content volume. Three screens is a demo. It fails AdSense, fails app review, and fails the first customer who lands on it.

None of these is exotic. All six are the difference between an app that works and an app that is ready.

Paste into your Base44 builder chat. The first one only reads — it changes nothing, so it is safe to run on a live app.

Audit this Base44 project for readiness to put in front of real users. Cover all
six areas below. I want to know what breaks on the day strangers arrive.

READ ONLY. Do not edit, create or delete any file, entity, schema or record. Do
not change an access rule. Do not run a security scan. Do not deploy. If
something should change, describe it — do not do it.

EVIDENCE RULE — this governs everything below.
Every finding must carry one of:
  [SCHEMA]      entity name and the rule block, quoted
  [CODE]        file path and line number
  [LIVE]        a URL you fetched, with the HTTP status code you received
  [UNVERIFIED]  you could not check it from here
No PASS, READY or "looks fine" without evidence. If you cannot check it, the
answer is UNVERIFIED. Never infer that something works because the code looks
like it should. Do not print the contents of any record — field names, status
codes and counts only.

…

Using the audit you just produced, fix the blockers. The audit was read-only;
this turn is the only one that writes.

BEFORE ANY ACCESS-RULE CHANGE, STOP AND ASK ME.
Some data is meant to be public — listings, articles, price lists, league tables.
List every entity you intend to restrict, say what you think it is for, and wait
for my answer. Clamping an intentional public read takes the live site down, and
that is a worse day than the one we are trying to avoid.

Order:
  P0  personal data readable by anyone
  P0  backend functions callable with no authentication
  P0  anything that stops the app loading or publishing at all
  P1  request loops that will 429 under real load
  P1  pages that should be noindex and are not, or vice versa
  P2  content and copy gaps

Do not:
…

Verify the app is actually ready. Do not trust the previous turn's report.

PART 1 — FETCH IT ALL FRESH, REPORT RAW RESULTS
  - custom domain root, with and without www: status codes, and which redirects
  - the TLS certificate: valid, and issued for this domain?
  - /robots.txt and /sitemap.xml: status, and sitemap URL count
  - every URL in the sitemap: how many return something other than 200? List them
  - the three most important routes: title, meta description, canonical, any
    robots meta tag, and whether body text is present in the response
  - every entity that was unruled before, fetched with no authentication:
    status code and NUMBER of records returned, never the records themselves
  - every backend function that had no auth check, fetched logged out: a 401 is
    what you want

For each, PASS, FAIL or UNVERIFIED against what the fix turn claimed. Where the
fetch and the claim disagree, the fetch wins — say so plainly and show the value.

PART 2 — THE THINGS ONLY I CAN DO
…

• Base44 status pageCheck before you blame your own app. Platform-wide limit tightening has happened and looks identical from inside.
• Base44 — running a security scanRun it, but verify by hand — builders report findings that will not clear.
• Base44 — Apps API rate limitsThe three entity write limits are the same on every plan, Enterprise included.
• Base44 — checking your SEO and GEOPer-page indexing, meta, llms.txt. Login-gated pages are always excluded from search.
• Base44 — connecting an external domainIncluding the traps: no AAAA records, and www on a subdomain needs a support ticket.
• Google Search ConsoleWhere you confirm what HTML Google actually receives.