Platform Capability Matrix

Generates auth UI but missing session persistence — server components can't read the session because the browser client is used instead of the SSR client.

Auth flow generated correctly but getSession() used in server context instead of getUser() — returns stale data after logout.

Auth generated using Replit's built-in auth or NextAuth — works in Replit environment but configuration breaks when migrating to Vercel or Railway.

OAuth callback route generated without exchangeCodeForSession — user is redirected in a loop and never signed in.

OAuth callback route present but exchangeCodeForSession is sometimes omitted — depends on prompt wording.

OAuth works within Replit hosting. Callback URLs hardcoded to repl.co domain — breaks on any other deployment target.

Same missing callback issue as Google OAuth.

Same variability as Google OAuth. Explicitly requesting 'GitHub login' in the prompt improves output.

Same callback URL issue as Google OAuth.

Works in preview environment. Breaks in production because success/cancel URLs are hardcoded to localhost.

Stripe Checkout session creation generated correctly. Success/cancel URLs use environment variables.

Stripe integration generated but webhook URLs point to the Replit development URL — non-persistent, changes on reboot.

Missing stripe.webhooks.constructEvent() — signature verification skipped entirely. Also uses request.json() instead of request.text(), which destroys the raw body Stripe needs for HMAC verification.

Webhook handler generated with constructEvent() present but often uses request.json() instead of request.text() — signature verification throws on every real Stripe event.

Webhook handler missing signature verification. The Replit environment makes webhook testing difficult, so this is often left broken.

All tables created with Row Level Security disabled. Any visitor with the public anon key can read, update, or delete every row.

Tables created without Row Level Security enabled. Same issue as other AI platforms — the anon key gives full database access.

When Supabase is used, RLS is not enabled — same pattern as other AI platforms.

Schema applied directly via Supabase dashboard — no migration files generated. No rollback path if something goes wrong.

Schema managed via Supabase dashboard, not migration files. Loveable does generate some SQL but doesn't wire it to a migration workflow.

Uses the correct Supabase connection string with connection pooling enabled.

Connection string generated correctly.

Replit Agent defaults to SQLite for the database. SQLite is not persistent across Replit restarts and cannot scale — not production-ready.

Deploys correctly to Vercel. Environment variables must be manually copied from the Bolt.new editor to Vercel project settings.

Vercel deployment works well. Loveable's export feature provides a clean Next.js project.

Significant rework required. SQLite must be replaced, environment variables reconfigured, build pipeline adjusted. See the full migration guide.

Requires manual DATABASE_URL adjustment. Generated config targets development database.

No Railway-specific config generated — requires manual setup.

Railway is the recommended migration target — supports persistent PostgreSQL and similar Node.js hosting model.

Dockerfile generated but often missing a /health endpoint — Fly health checks fail on first deploy.

Netlify deployment also supported via export.

Works correctly within Replit's own hosting infrastructure.

Frequently prefixes server-only secrets (STRIPE_SECRET_KEY, OPENAI_API_KEY) with NEXT_PUBLIC_ — these are bundled into client JavaScript and visible in browser DevTools.

Less frequent than Bolt.new but NEXT_PUBLIC_ prefix errors still occur on sensitive keys when the developer iterates quickly.

Replit's Secrets management is used for env vars, but public Repls expose their code — secrets must be explicitly marked.

Service role key occasionally used in client components when the developer asks for 'admin database access'. Bypasses all RLS policies.

Service role key generally kept server-side in generated code.

When Supabase is added, service role key handling is inconsistent.

No rate limiting generated on any API routes — email, AI, and auth endpoints are all open to abuse.

No rate limiting on generated API routes.

No rate limiting generated.

Client-side form validation only. API routes accept and insert arbitrary input without server-side validation.

Zod schemas sometimes generated for forms, but API route validation is inconsistent.

Validation inconsistent across generated projects.