An AI powered app builder that ships a real backend before the agent reads your prompt
mk0r does not start with a UI sketch. Every new session fires four parallel API calls and hands the AI live credentials for Neon Postgres, Resend, GitHub, and PostHog. Here is what that means for the apps it builds.
The story everyone else tells stops at the UI
Read any guide on this topic and you will see the same arc. Type a sentence, watch a screen render, ship a landing page. That story is fine for a marketing site or a calculator, but it skips the part where most apps actually live: the database, the email sender, the source repository, the analytics that tells you if anyone touched the thing.
mk0r treats those as the first move, not the last one. Before the agent so much as reads your prompt, four real backend resources already exist for your app. The credentials are mounted inside the sandbox. The agent uses them.
The four services, side by side
Each one is a real account at a real provider. They are not stubs, and they are not deferred. By the time you finish typing your prompt, all four exist.
Provisioning fan-out for a single session
How the orchestrator runs
The function that does the work lives at src/core/service-provisioning.ts. PostHog is wired synchronously, since it reuses a shared project key. Resend, Neon, and GitHub each make their own POST request, and they run in parallel using Promise.allSettled so a failure on one provider never blocks the others.
What you would see in the logs
Why this matters for the apps the AI ships
An AI agent that has a real Postgres URL will write code that inserts rows and reads them back. An AI agent that has a Resend key will write code that calls resend.emails.send() instead of leaving a TODO. The agent does not have to invent credentials, ask you for keys, or pretend that localStorage is a database. It is told, in plain language inside its CLAUDE.md, to read /app/.env first.
env vars on the agent's filesystem at first turn
- DATABASE_URL pointing at a fresh Neon Postgres 17 endpoint
- RESEND_API_KEY restricted to sending access for this app only
- RESEND_AUDIENCE_ID for capturing user emails
- GITHUB_REPO and GITHUB_REPO_URL for a private repo under m13v/
- VITE_POSTHOG_KEY, VITE_POSTHOG_HOST, VITE_POSTHOG_APP_ID for event isolation
- NEON_HOST, NEON_DB_NAME, NEON_ROLE_NAME, NEON_ROLE_PASSWORD for direct psql access
What sits inside each service
Neon Postgres
Per-app project on aws-us-east-2 running PostgreSQL 17. Connection URI, host, db name, role, and password all wired into /app/.env.
Resend
Audience created via POST /audiences. A second POST /api-keys mints a restricted key with sending_access permission scoped to this app.
GitHub
Private repo at m13v/mk0r-<sessionSlug>, created via POST /user/repos with auto_init disabled so the agent owns the first commit.
PostHog
Shared project key plus a per-app group id of the form mk0r-<sessionSlug>. Events from your app stay isolated by group property.
Hot module reload
Vite dev server runs at localhost:5173 inside the sandbox. The agent edits /app/src, your preview updates instantly.
From your sentence to the agent reading credentials
Session lifecycle
You type a sentence on mk0r.com
No login, no form. The home page accepts a single text input and a session key is generated server-side.
The session key becomes the stable namespace for every backend resource attached to your app. It is a 12-character slug derived from the session id.
Provisioning fires before the agent boots
provisionServices() in src/core/service-provisioning.ts runs PostHog synchronously and Resend, Neon, and GitHub in parallel via Promise.allSettled.
Each call has a 15 to 30 second timeout. Failures from one provider never block the others, so a slow Resend response does not stall Neon or GitHub.
Credentials are written into /app/.env
buildEnvFileContent() concatenates the env vars and writes them into the sandbox at /app/.env before the AI session begins.
Trailing newlines are stripped. The file lives next to package.json so Vite picks up VITE_*-prefixed variables without further wiring.
The agent reads the env file and builds
The agent's CLAUDE.md tells it to check /app/.env for pre-provisioned services before creating new accounts or asking the user for API keys.
The agent uses pg or postgres-js for storage, the Resend SDK for transactional email, and posthog-js for analytics. No mocks, no placeholders.
Compared with the typical AI builder workflow
Most existing tools target the UI layer and treat backends as something you bolt on later. The table below is the version of the same idea you have probably seen elsewhere, lined up against what mk0r does inside one session.
| Feature | Typical AI builder | mk0r |
|---|---|---|
| Database access in the first generation | Schema is described in markdown, you wire the connection later | DATABASE_URL points at a live Neon Postgres 17 endpoint inside /app/.env |
| Sending email from the generated app | Placeholder code with TODO: add SMTP credentials | Restricted Resend API key created via api.resend.com, scoped to sending_access |
| Source control for the generated code | Download a zip and create a repo yourself | Private GitHub repo opened automatically, repo URL returned with the session |
| Analytics on the generated app | Suggested in the README, not wired up | PostHog client initialized with a per-app group id so events stay isolated |
| Account required to start | Email, password, sometimes credit card | None. The provisioning runs under shared infrastructure mk0r owns |
Comparison reflects the default flow on each platform as of April 2026.
Names you already use, wired before you ask
These are not third-party connectors hiding behind a marketplace. They are the providers mk0r calls directly during provisioning.
The numbers that fall out of this design
A pre-baked sandbox image plus parallel provisioning means you are not paying for the sum of the slow parts, only the slowest one. The Neon project creation usually wins that race at roughly 0s, while Resend and GitHub each finish in a few hundred milliseconds. The sandbox itself boots from a snapshot in about 0s.
What you should expect from a session
When the agent comes back to you with a working app, expect to see a few specific things you would not get from a UI-only tool. Forms persist on a real Postgres row instead of a JavaScript object. The login email lands in your inbox via Resend instead of being logged to the console. The repo on GitHub already has the agent's first commit. Your PostHog dashboard already shows the first pageview, tagged with the per-app group id.
The takeaway: an AI powered app builder that does not control the backend ends up generating frontend toys. mk0r is the opposite case. The backend exists first, and the agent writes code against it.
Want to see the four POSTs fire on your prompt?
A live walkthrough of provisioning, /app/.env, and the agent's first turn. 15 minutes, no slides.
Frequently asked questions
What does mk0r set up before the AI agent starts coding?
Four things, in parallel. A Neon Postgres project named mk0r-<sessionSlug> running PostgreSQL 17 in aws-us-east-2. A Resend audience plus a per-session API key with sending_access permission. A private GitHub repo under m13v/mk0r-<sessionSlug>. A PostHog group with app id mk0r-<sessionSlug> for event isolation. The credentials are written to /app/.env inside the sandbox before the agent reads your prompt.
Why does the AI agent get a real database instead of a mock?
Mocked data lies. An app that works against a fake JSON file falls over the first time real users sign up. mk0r writes DATABASE_URL, NEON_HOST, NEON_DB_NAME, NEON_ROLE_NAME, and NEON_ROLE_PASSWORD into /app/.env, and the agent's instructions tell it to read those variables before creating any storage layer. The result: forms persist, queries are real Postgres queries, and the app you see in preview is the same shape as the one you would deploy.
Can I see the credentials and the GitHub repo afterward?
Yes. The Neon project, GitHub repository, and Resend keys are real resources in real accounts. The repo URL comes back as GITHUB_REPO_URL in /app/.env. The Postgres connection string in DATABASE_URL points at the live Neon endpoint. You can connect from any psql client, push commits to the GitHub repo, and watch PostHog events flow with the unique app id.
What happens if one of the provisioners fails?
Provisioning uses Promise.allSettled, so a failed Resend call does not block Neon, GitHub, or PostHog. The orchestrator returns whatever succeeded plus a list of error objects. The agent's CLAUDE.md tells it to check that an env var exists before using it, so a missing service degrades gracefully instead of crashing the build.
How is this different from a starter template that ships with a config file?
A starter template gives you placeholders and asks you to fill in keys. mk0r executes the API calls itself: POST to console.neon.tech for the database, POST to api.resend.com for the audience and the restricted key, POST to api.github.com for the repo. By the time the AI sees your prompt, the resources exist and the credentials are mounted.
Do I need an account to use mk0r?
No. mk0r requires zero signup. You type a description and the orchestrator provisions backend resources under shared infrastructure that mk0r owns. There is no email field, no password, no credit card, no onboarding flow.
What does the agent actually build with these credentials?
The in-VM agent is a Claude Code session running inside a Vite + React + TypeScript + Tailwind v4 project at /app. It edits files in /app/src, runs the dev server at localhost:5173 with HMR, opens Chromium via Playwright MCP to verify the UI, and uses the Postgres URL, Resend key, and PostHog token directly when the app needs persistence, email, or analytics.
How long does the provisioning take?
Resend, Neon, and GitHub run as Promise.allSettled, so the slowest of the three sets the wall-clock cost. Neon project creation is the longest leg at roughly 10 to 20 seconds. The pre-baked E2B sandbox boots from a snapshot in about 2.5 seconds, and the env file is written before the agent's first turn, so by the time you finish typing your prompt the backend is usually already live.
Other guides on the parts of mk0r that show up in the same session
Keep reading
AI App Builder with a Backend
How mk0r ships database access, auth, and APIs in the same session that builds the UI.
AI App Maker with a Database
What you can do once your generated app already has DATABASE_URL pointing at a real Postgres.
AI App Maker with Browser Testing
The agent runs Chromium inside the sandbox and verifies the app it just built. No manual QA pass needed.