The AI app builder data and auth wall, dissolved in one server step

Two compounding gates that fire before your prototype can do anything real. The auth wall is the signup form, the verification email, and the credit card prompt that block your first prompt. The data wall is what hits five minutes later: the prompt has produced a UI but it has nowhere to write to, no email it can send, and no Git history it can commit to, because most builders sandbox you in browser localStorage. You cross the auth wall with a 90 second signup flow, then you cross the data wall by personally registering for Neon, Resend, GitHub, copying connection strings, and pasting them into env vars. The keyword bundles both because in practice they hurt at the same time.

On first visit, the AuthProvider quietly calls signInAnonymously through Firebase, so you have a real uid before you have ever seen a sign-in screen. When that anonymous uid sends its first prompt, the server calls provisionServices(sessionKey) in src/core/service-provisioning.ts. Inside that function, Promise.allSettled fires three external API calls in parallel: provisionResend creates a Resend audience plus a sending-only restricted API key, provisionNeon creates a Postgres 17 project in aws-us-east-2 under org-steep-sunset-62973058, provisionGitHub creates a private repo at m13v/mk0r-{slug}. PostHog runs synchronously and gives you a per-app appId. Both walls fall in the same allSettled call.

A /app/.env file written by buildEnvFileContent(envVars). It contains DATABASE_URL with a real Neon connection URI, NEON_HOST, NEON_DB_NAME, NEON_ROLE_NAME, NEON_ROLE_PASSWORD for direct connections, RESEND_API_KEY plus RESEND_AUDIENCE_ID for transactional and audience email, GITHUB_REPO plus GITHUB_REPO_URL for the private repo the VM commits into, VITE_POSTHOG_KEY plus VITE_POSTHOG_HOST plus VITE_POSTHOG_APP_ID so the in-VM client emits events under a per-app group. The agent reads this file on boot. You did not paste any of those values yourself.

Because the gate that usually triggers data provisioning is identity. Most builders refuse to give you a real database until you have an account, a billing record, and an email confirmation, because they do not want to provision pay-as-you-go infrastructure under a ghost. mk0r inverts that: it owns the Neon org, the Resend account, the GitHub org, and the PostHog project, and it provisions per-app resources under those parent accounts using server-side API keys (NEON_PROVISIONING_KEY, RESEND_PROVISIONING_KEY, GITHUB_PROVISIONING_TOKEN). Your anonymous uid is the routing key, not the billing key. So the first iteration has no signup, no payment screen, and a real Postgres, all at once.

Real. Look in src/core/service-provisioning.ts at provisionNeon. It POSTs to https://console.neon.tech/api/v2/projects with pg_version 17 and region_id aws-us-east-2, parses connection_uris[0].connection_uri, and writes that exact URI into /app/.env as DATABASE_URL. The agent inside the VM uses @neondatabase/serverless, runs migrations, and writes rows. There is no in-memory shim and no IndexedDB fallback. If you delete the VM and start a new session, you get a new project; if you stay in the same session, your rows survive page refreshes and container restarts.

No. Each app gets its own resources: a separate Neon project keyed mk0r-{slug} where slug is the first twelve characters of the session key, a separate Resend audience and restricted API key, a separate private GitHub repo, a separate PostHog appId. The slug isolation is enforced at the slug-generation layer in src/core/service-provisioning.ts (appSlug(sessionKey)), and the API key for each Resend integration is created with permission 'sending_access' so it can only send mail. There is no shared Postgres role, no shared GitHub repo, and no Resend audience that can read another app's subscribers.

It is moved to the actions that move money. requireAuth(action) in src/components/auth-provider.tsx wraps the publish button, the model selector, and a few billing-adjacent settings. The prompt textarea, the VM preview, the editor, and provisioning itself are not gated. On the server, requireAuthOrError in src/lib/auth-server.ts verifies the Firebase ID token on routes that mutate persistent state, and billing endpoints additionally require a paid entitlement before they let a request through. The auth surface is small and lives where the cost lives, not at the front door.

Nothing breaks. Sign-in goes through linkWithPopup, which merges the Google credential into the anonymous uid, so the same uid keeps owning the Firestore session that points at the Neon project, the Resend audience, the GitHub repo, and the PostHog appId. If linkWithPopup throws auth/credential-already-in-use because that Google account already has a Firebase uid from another device, the client falls back to signInWithCredential and POSTs /api/auth/migrate. The server runs migrateSessionOwnership, a single Firestore batch that re-points every app_sessions and projects doc onto the new uid. Your provisioned services do not move; the pointer to them does.

The three external calls (Resend audience, Resend API key, Neon project, GitHub repo) run with abort timeouts of 15 seconds each, except Neon which is given 30 seconds because project creation is the slowest external dependency. Promise.allSettled means the slowest call sets the wall clock and the others overlap fully behind it. In practice, Neon is the bottleneck and the whole step finishes inside the time it takes the E2B sandbox to boot and start the dev server, so you do not feel the latency on the first prompt.