How to audit an app that lives behind a login
The one-page trick that lets CrashBadger (or any external QA tool) actually see your app.
01 · The problem
Almost every AI-built app follows the same shape: landing → auth → app. An external crawler that shows up cold only ever sees the marketing landing page. It never reaches the dashboard, the empty state, the onboarding wizard, or the core flow.
Which means the findings that matter most — the ones your real users hit in the first 30 seconds — stay invisible to every QA tool you point at your live URL.
02 · The solution
Stand up an unlisted, fully empty demo instance of your app: a blank tenant, demo workspace, or seeded test-account view that is publicly loadable by direct URL but not linked from anywhere and not indexed by search engines.
Then point CrashBadger at that URL — not your marketing site. CrashBadger now crawls the actual app UI a signed-in user would see.
03 · Prompt for your AI builder
Paste this into Lovable, v0, Bolt, Base44, Replit, or any AI coding assistant. It's written builder-agnostic on purpose.
Create a public "demo instance" of this app for external QA testing. Requirements: 1. Create a real, fully functioning instance/tenant/workspace using the app's existing architecture — NOT a mock, NOT a fake page, NOT a static screenshot. It must render the actual app UI, routes, and components that a real signed-in user would see. 2. The instance must be completely empty: no seeded records, no example content, no contact info, no payment configuration, no real user data, no API keys, no connected integrations. Empty tables, empty lists, empty dashboards — the true first-run experience. 3. The instance must be publicly accessible by direct URL with NO login, NO password, NO email gate, NO invite code required. 4. It must be unlisted: do not add it to any navigation, sitemap, directory, or search index. Add <meta name="robots" content="noindex, nofollow" /> to every page of the instance. Do not link to it from the landing page or marketing site. 5. All write actions inside the demo instance should either be disabled or scoped so they never leak into production data (e.g. a throwaway tenant id, ephemeral storage, or read-only mode). 6. When finished, return the final public URL of the demo instance so I can point an external QA tool at it. Do not create fake pages or a marketing preview. I need the real app, empty, at a public URL.
04 · Why an empty instance is the best test
An empty instance shows exactly what a brand-new user sees on their first ever visit — and empty states are precisely where AI-built apps most often break. Zero-row tables that render as broken layouts, dashboards built assuming data exists, "0 results" flows nobody ever styled, onboarding steps that silently 500 when a field is null.
A seeded demo hides all of that. An empty demo surfaces it.
05 · Security caution
Anything reachable by URL is reachable by anyone — search engines eventually, scrapers immediately, curious strangers whenever they feel like it. Your demo instance must therefore contain:
- No real customer data or PII
- No live payment provider keys (Stripe test mode only, or nothing at all)
- No production API keys, webhook secrets, or connected accounts
- No email/SMS providers that could be used to spam real inboxes
- No write-through to your production database
Treat the demo instance as if it will be found. Because it will.