The no code AI app builder that boots before you type
Every other guide on this topic describes the same flow. You sign up, you click Create new project, you wait while a container provisions, then you finally type a prompt. mk0r runs the wait in the opposite direction: a Firestore-backed pool of warm sandboxes is already topped up by the time you finish reading the hero. Your first prompt claims a runtime, it does not start one.
The thing nobody else writes about
Open any list-style article about no code AI app builders. They all cover the same surface: the model behind it, how many templates it ships with, whether it has an iOS export, what the free tier looks like. None of them look at the part you actually feel: the wait between hitting build and seeing your app on a real URL. That wait is where most builders spend the first thirty to ninety seconds of your trust, and it happens because every step of the runtime stack starts cold the moment you click.
mk0r treats the boot as a pre-computable side effect of someone visiting the homepage. The infrastructure you would have waited for is already up. This is the part of the product nobody else has, and it is the only honest reason this page exists.
Where the warmup happens
The landing page mounts, and three lines of React fire a single POST to /api/vm/prewarm. The response is ignored. The point is the side effect on the server.
What that endpoint actually does
The endpoint runs topupPool() against a Firestore collection called vm_pool. Each entry tracks a booted E2B sandbox, the ACP URL, the preview URL, the session ID, and a specHash tied to the current template ID. Stale entries are reaped on every call. If the pool is below its target size, the endpoint boots more in the background.
The pool architecture, end to end
The six boot steps you no longer wait for
When mk0r has to boot a sandbox cold, six labeled steps tick through the progress bar in BootProgress. When the pool has a ready entry, you experience exactly one step: pool_claim. Here are the six steps, copied straight out of the source.
With a cold boot vs. with a warm pool entry
First prompt has to wait for the entire stack to come up. Six labeled steps run sequentially. Each one is small on its own, but together they account for most of the perceived load time on every other no code AI app builder.
- session_check (Firestore lookup)
- vm_boot (E2B sandbox start)
- acp_init (agent runtime initialize)
- acp_session (new session, MCP wire-up)
- model_setup (Haiku selected)
- git_setup (local repo init)
How a single prompt flows through it
Below is what happens between the moment you type a sentence and the moment the preview shows your app. The choreography is identical whether the pool is warm or not. The difference is which steps the code runs versus which steps a previous visitor already paid for.
From keystroke to running app
You land on mk0r.com
src/app/(landing)/page.tsx mounts. useEffect fires fetch('/api/vm/prewarm', { method: 'POST' }) once. The session key is read from localStorage or generated.
The pool tops up while you read
topupPool() in src/core/e2b.ts checks how many ready entries exist in the vm_pool Firestore collection. If the count is below VM_POOL_TARGET_SIZE, it kicks off prewarmSession() calls in parallel. Each one boots a fresh E2B sandbox, runs ACP /initialize and /session/new, sets the model to haiku, and writes a 'ready' doc to Firestore.
You type a prompt
The chat handler calls getOrCreateSession with your session key. The function checks Firestore for a saved session, then tries claimPrewarmedSession before booting fresh. The pool path collapses session_check, vm_boot, acp_init, acp_session, model_setup, and git_setup into a single pool_claim step.
ACP is re-initialized with your credentials
The pool entry was warmed with the shared ANTHROPIC_API_KEY. claimPrewarmedSession swaps that for your OAuth token (or your own key if you brought one), so your usage is billed correctly and the agent runs under your identity.
The agent reads its rulebook
globalClaudeMd is already on disk inside the sandbox at /root/.claude/CLAUDE.md, written when the pool entry was warmed. projectClaudeMd is at /app/CLAUDE.md. The agent reads both before it processes your first token.
The preview renders, the pool refills
Vite is already running on port 5173 inside the sandbox with HMR over wss. Your code lands, HMR pushes it to the iframe in the preview panel, and you see your app. In parallel, void topupPool() runs again so the next visitor also gets a warm claim.
What a topup looks like in logs
Every boot emits structured events. When you POST /api/vm/prewarm with no warm entries available, the log line sequence looks roughly like this. The names match the flog calls in src/core/e2b.ts.
Why it matters for a no code workflow
People who use a no code AI app builder are not waiting because they enjoy debugging. They are waiting because that is what every tool in this category has trained them to expect. Cutting the wait changes the shape of the workflow. The first prompt becomes cheap to throw away. You can rephrase, pivot, restart. The cost of trying something the agent gets wrong drops, which is the whole point of describing apps in plain English in the first place.
Pool target is configurable
VM_POOL_TARGET_SIZE on Cloud Run sets how many warm sandboxes to keep ready. Default is 1. Bumping it for high-traffic windows is a one-line env var change.
Stale entries get reaped
cleanupStalePool() runs on every prewarm. It deletes any pool doc older than 45 minutes or whose specHash does not match the current template, and kills the underlying E2B sandbox so nothing leaks.
Topup is idempotent
Concurrent topup calls do not overshoot. Each call writes a 'warming' reservation doc first, so two parallel prewarms cooperate instead of double-booting.
Auth swaps at claim time
The pool boots with the shared key so the warmup does not depend on a logged-in user. claimPrewarmedSession re-initializes ACP with your token before handing the session to the chat handler.
No client polling
The homepage POST is fire-and-forget. The browser does not wait for a response, so the preconnect adds no perceptible cost to your page load.
Cron friendly
The same /api/vm/prewarm endpoint is meant to be hit by an external scheduler. Setting POOL_ADMIN_TOKEN gates it behind a bearer secret if you do not want the public mount-ping in production.
What this looks like across the category
The other tools in the category are real and well-built. They are not stupid for not having a pool. They run different shapes: multi-tenant Kubernetes, container pre-pulls, edge sandboxes, persistent workspaces. The trade-offs differ. The user-visible outcome at first prompt is what we can compare honestly, and on that single axis mk0r is faster because of one design choice no article about the category has put in writing.
| Feature | The typical no code AI app builder | mk0r |
|---|---|---|
| Account required before first prompt | Yes, email plus a verification step | No. Anonymous session, key in localStorage |
| Click-create-project step before first prompt | Yes, project name plus framework picker | No. The prompt itself creates the project |
| Sandbox boot timing | After click, end to end on the user | Before visit, into a Firestore vm_pool |
| Boot steps the user experiences | All of them, sequentially | One: pool_claim, when the pool is warm |
| Self-tests in a real browser before reporting done | Optional, often skipped | Required by the agent rulebook (Playwright MCP) |
| Source code for the boot path is readable | Closed | Open in src/core/e2b.ts and src/components/boot-progress.tsx |
Numbers from the source
Every number below comes from src/core/e2b.ts or src/components/boot-progress.tsx. Open the repo and count.
Honest limits
The pool is a latency optimization, not magic. If traffic spikes past VM_POOL_TARGET_SIZE, the next user falls back to a cold boot. If the template hash changes (after a deploy that touches the E2B template), the old pool gets reaped and the next several requests pay the full boot cost while the pool refills. If your country requires a residential proxy, the proxy is enabled at claim time, which adds a small additional step. The honest answer is that the pool helps the steady state, not the worst case. The worst case still works; it just does not feel different from any other no code builder.
Want to watch a warm claim in real time?
Book 20 minutes. We will open the network panel together, hit /api/vm/prewarm, then describe an app and watch the pool_claim event collapse the six step bar into one.
Frequently asked questions
What is a no code AI app builder?
A no code AI app builder lets you describe an app in plain English and get back working code without writing any yourself. The AI handles the implementation. mk0r is one example. Bolt, Lovable, v0, and Replit Agent are others. The differences usually come down to what you have to do before the AI starts building, and how long it takes to get a running preview.
What do you mean mk0r boots before I type?
When you load mk0r.com the landing page fires a fetch to /api/vm/prewarm on mount. That endpoint calls topupPool(), which makes sure a Firestore collection called vm_pool has at least one warm E2B sandbox sitting ready. The sandbox already has Vite, React, TypeScript, Tailwind v4, Playwright, and the agent rulebook loaded. By the time you finish reading the hero, there is a runtime waiting for your first prompt. You can verify this in src/app/(landing)/page.tsx and src/core/e2b.ts.
How is that different from Bolt or Lovable or v0?
Most builders only start provisioning after you click 'create new project' or after you sign up. The boot you experience is end to end: container start, framework install, dev server warmup, agent initialization. On mk0r the bulk of that work happened before your visit. You experience one step (pool_claim) instead of six (session_check, vm_boot, acp_init, acp_session, model_setup, git_setup). The labels are visible in src/components/boot-progress.tsx.
What if no warm sandbox is available?
You boot a fresh one and watch the six step progress bar tick through. The agent still works the same way. The pool just turns the cold start into a warm start when the timing lines up, which is most of the time when traffic is steady. Pool size is controlled by the VM_POOL_TARGET_SIZE env var on Cloud Run.
Do I really not need an account?
Right. The landing page issues you a session key in localStorage and sends it to the API. You can build, iterate, and preview without ever submitting an email. Sign in is only required if you want to keep your project across browsers, publish to a custom domain, or pay for usage beyond the free tier.
What kind of apps fit a no code AI app builder?
On mk0r the most common output is a Vite + React + TypeScript + Tailwind app at /app inside the sandbox, with a real dev server on port 5173 and HMR over wss. That covers waitlists, dashboards, internal tools, marketing sites, calculators, scrapers, scheduling pages, and CRUD UIs over a real Postgres database. The agent has Playwright MCP, so it tests its own work in a real browser before reporting completion. It is not the right tool for kernel patches, native iOS code, or systems that need to run on bare metal.
How long does the warm sandbox stay in the pool?
POOL_MAX_AGE_MS in src/core/e2b.ts is set to 45 * 60 * 1000 milliseconds, which is 45 minutes. The underlying E2B sandbox has a one hour timeout, so the pool entry is retired before the sandbox is reaped. cleanupStalePool() runs on every prewarm and kills any entry that has aged out or whose specHash no longer matches the current template.
Can I read the code that does this?
Yes. The whole pool implementation is in src/core/e2b.ts starting at the comment 'Pool: Firestore-backed pre-warmed sandbox pool' around line 1844. The HTTP endpoint is in src/app/api/vm/prewarm/route.ts. The boot step labels are in src/components/boot-progress.tsx. The landing page hook that fires the warmup is in src/app/(landing)/page.tsx around line 63. None of it is hidden.
By the time you finish reading this paragraph, a sandbox warmed by the last visitor is already waiting for your prompt. There are 0 boot steps in the source. You will only ever see one of them.
Build on mk0r