AI web app builder: the three categories, and which one you actually need
Most articles on this topic compare features. The thing that actually decides whether you keep using a tool is which of three categories it falls into: static HTML generator, closed no-code platform, or real dev environment with an AI agent. Pick the right category first, then compare features inside it.
There are three categories of AI web app builder.
- Static HTML generators. One file in, one file out. Good for a landing page or a one-shot demo. Examples: Claude Artifacts, basic prompt-to-page tools.
- Visual no-code platforms.Your app lives as a schema inside the vendor's database. Fast to ship, hard to leave. Examples: Bubble, Glide, Softr.
- Real dev-environment agents. The agent edits a normal source tree (TypeScript, JSX, CSS) inside a sandbox running an actual dev server. You can download the project and keep working. Examples: mk0r, Bolt, v0, Lovable.
mk0r is in the third category. The sandbox runs Vite + React + TypeScript + Tailwind CSS v4, the dev server is on port 5173 with HMR, and the project tree the agent edits is a normal Vite repo you can pull out and keep developing.
Why the category decides everything
The same prompt, “build me a habit tracker,” produces wildly different output depending on what the tool is allowed to do underneath. A static-HTML tool emits one file with hardcoded mock data. A no-code platform builds a database row, a form bound to it, and a list view. A dev-environment agent scaffolds a Vite + React project, installs a charting library if it wants one, runs a build, and tests the UI.
You will not feel the difference for the first ten minutes. You will feel it on day three when you ask for a feature the first two categories cannot reach. So the right question to ask up front is not “which tool has the prettiest hero?” The right question is “which category am I picking, and is that the right ceiling for the thing I am trying to ship?”
Static and no-code, vs a real dev environment
The first two categories collapsed into one column for brevity. Their tradeoffs differ from each other, but both diverge from the third category along the same axes.
| Feature | Static / no-code | mk0r (real dev environment) |
|---|---|---|
| What you actually get | A single HTML/CSS/JS file or a closed visual schema | A normal Vite + React + TypeScript project tree |
| Can you run it locally? | Static file: yes. No-code platform: no, you rent the runtime | Yes. `npm install && npm run dev` and you have the same server |
| Hot reload during iteration | No (regenerate full file) or platform-specific preview | Vite HMR on port 5173. Edit a file, the running app updates |
| Agent can test its own UI | Rare. Most builders cannot drive a real browser | Playwright MCP on Chromium CDP port 9222 inside the sandbox |
| Can you install npm packages? | Static: no. No-code: only what the platform allows | Yes. The agent runs `npm install <pkg>` like a normal dev |
| Lock-in | High on no-code platforms, low on static generators | Low. Output is a normal Vite repo you can take with you |
| Account required to start | Almost always yes | No. Browser session UUID, sandbox pre-warmed before you type |
What “real dev environment” actually means inside mk0r
The interesting part of category three is the substrate. Most marketing copy for AI app builders waves at “running in a sandbox” without telling you what that sandbox actually is. Here is what mk0r's sandbox is, with file paths so the claims are checkable.
The Dockerfile
The E2B template is built from the Dockerfile at docker/e2b/e2b.Dockerfile. The two lines that set the entire web stack:
That is the standard Vite React-TypeScript template plus Tailwind CSS v4. No custom fork, no proprietary build tool. The same command you would run to scaffold a project on your own laptop.
The system prompt
One paragraph. The agent reads CLAUDE.md files inside the project for the rest. From src/core/e2b.ts at line 148:
“The dev server is running on port 5173 with HMR. You have Playwright MCP for browser testing.”
DEFAULT_APP_BUILDER_SYSTEM_PROMPT, src/core/e2b.ts line 149
The browser the agent uses
The MCP config built by buildMcpServersConfig() installs @playwright/mcp@0.0.70 globally inside the sandbox and points it at http://127.0.0.1:9222, which is the Chromium remote debugging port. So when the agent calls a browser tool, it is driving the same headless Chromium that mk0r's preview iframe shows you. Same DOM, same CSS, same network. The agent can verify its own UI without leaving the sandbox.
Walk through one prompt, end to end
Here is the path a single prompt takes through mk0r's real-dev-environment stack. Every step maps to a real piece of code in the public repo.
One prompt, six moments
Page mount fires the pre-warm
Your browser hits /api/vm/prewarm on first paint. The endpoint asks Cloud Run to grab a warm E2B sandbox from the pool while you are still reading the textarea placeholder.
E2B template boots the dev environment
Template id 2yi5lxazr1abcs2ew6h8 starts on 4 CPU and 4 GB RAM. /opt/startup.sh launches the ACP bridge, Xvfb, Chromium with --remote-debugging-port=9222, and `npm run dev` for the Vite server on port 5173.
Agent reads the one-paragraph system prompt
The constant DEFAULT_APP_BUILDER_SYSTEM_PROMPT in src/core/e2b.ts at line 148 tells the agent it is in a Vite + React + TypeScript + Tailwind v4 project at /app and that Playwright MCP is available. Detailed rules live in the project's CLAUDE.md files, which the agent reads at runtime.
Your prompt streams in, files start changing
The agent edits src/App.tsx, src/main.tsx, src/index.css, and any new files it creates. Vite picks up the change, sends the diff over the HMR socket, and the iframe in the mk0r tab repaints without a full reload.
Agent verifies its own work
If the prompt asks for behavior the agent is not sure about (a button click, a form submit), it can spawn the Playwright MCP server (@playwright/mcp@0.0.70), navigate to the dev URL, and assert what it sees. mk0r's UI detects browser tool calls so the preview surface knows the agent is testing.
You iterate or download
Type a follow-up. Same sandbox, same dev server, additive change. Or pull the project tree out and keep working in any editor. The output is a normal Vite repo, not a proprietary format.
Picking the right category for your project
A useful rule: pick the lowest-ceiling category that fits your goal, then upgrade only when you outgrow it.
Static HTML
Pick when the lifespan is days and the surface is one page. Landing pages, one-shot demos, share-once experiments.
Visual no-code
Pick when the schema is known, the user count is small, and you trust the platform to still be around in two years. Internal tools, simple CRUD, intake forms.
Real dev environment
Pick when you might keep developing it. Product prototypes, demoable MVPs, side projects that could turn into real things. mk0r, Bolt, v0, Lovable.
Where mk0r is honest about limits
A real dev-environment AI builder is not a magic wand. The agent writes Vite + React + TypeScript, which is great for UI-heavy apps and not great for things the stack does not cover natively. Multi-user real-time state, production-grade auth flows, large background jobs, native mobile, anything that needs a long-running server you fully control: out of scope for the first draft, possible later when you take the project out of the sandbox and host it yourself.
The good news is that since the output is a normal repo, “take it out and host it yourself” is a thing you can actually do. You are not locked into the sandbox. The sandbox is a place to start, not a place to live.
Want to see the third category in action?
Open mk0r.com, type a prompt, and watch a real Vite + React project boot in a sandbox. Or book a 20-minute call and we will walk through your use case together.
Frequently asked questions
Is mk0r an AI web app builder, or just a prompt-to-HTML tool?
It is a real web app builder. When you start a session, mk0r boots an E2B sandbox using template id 2yi5lxazr1abcs2ew6h8 (4 CPU, 4096 MB RAM). The Dockerfile at docker/e2b/e2b.Dockerfile lines 70 to 72 runs `npm create vite@latest . -- --template react-ts` and installs Tailwind CSS v4 with the Vite plugin. The agent edits files inside that project. The Vite dev server on port 5173 serves the running app over HMR. You are not getting an HTML string, you are getting a normal Vite + React + TypeScript repo the agent is editing live.
What is the difference between an AI web app builder and a no-code platform like Bubble?
A no-code platform like Bubble or Glide stores your app as a visual schema in their database. You cannot export it as code and host it elsewhere; you are renting a runtime. An AI web app builder in the dev-environment category writes actual source files (TypeScript, JSX, CSS) into a project tree. mk0r writes into /app inside the sandbox and you can read every file. If the platform vanished tomorrow, the code itself does not.
Why does the substrate matter so much? It is just plumbing.
The substrate is the ceiling. If the runtime is a single HTML string, the agent cannot install a charting library, run a build step, or test its own UI. If the runtime is a real Vite dev server with a wired Chromium, the agent can `npm install recharts`, see the result hot-reload, and use Playwright MCP at @playwright/mcp@0.0.70 to click through its own pages on CDP port 9222 and catch its own bugs. Same prompt, very different output, because the runtime decides what is possible.
Do I need an account to use mk0r as a web app builder?
No. You open mk0r.com, the page mounts, and a session UUID is assigned to your browser. The pre-warm endpoint at /api/vm/prewarm gets called so a sandbox is ready before you finish typing. You can build, iterate, and download. The wall (subscription, model upgrade, custom domain) only shows up if you want non-free things like Sonnet/Opus or hosted publishing. Anonymous build is the default surface.
What stack does the generated web app actually use?
Vite + React 19 + TypeScript + Tailwind CSS v4 with the @tailwindcss/vite plugin. The default system prompt at src/core/e2b.ts line 149 names it explicitly: `Vite + React + TypeScript + Tailwind CSS v4 project at /app`. Dev server port is 5173. There is also an internal bridge file at /app/src/_mk0rBridge.ts that wires the running app back to the host page so the preview frame and the session stay in sync.
Can I keep developing the app outside mk0r?
Yes. The output is a standard Vite + React + TypeScript project. Clone the repo from your session, run `npm install`, run `npm run dev`, and you have the same dev server locally that the agent was running. Nothing in the project tree is proprietary, no special build runtime is needed. You can take the source to GitHub, to your own VPS, to Cloud Run, to a teammate's machine.
What is the right category of AI web app builder for me?
If you need a static landing page or a one-page demo and the lifespan is days, a prompt-to-HTML tool is fine. If you are building an internal tool with database tables, forms, and a known schema, a no-code platform like Bubble or Glide will save you time even though you cannot export the code. If you are prototyping a product, want to keep developing it, or want a real React codebase you or your team can iterate on, pick a dev-environment AI builder. mk0r is in that bucket along with Bolt, v0, Lovable, and a few others.
How long until I see something running?
First HTML streams within seconds in the lightweight mode. In VM mode, the sandbox is pre-warmed when the page mounts, so by the time you finish typing the first prompt the Vite dev server is already up on port 5173 and the preview iframe is ready to receive the URL. End-to-end first-paint of a generated app is typically 1 to 3 minutes depending on how much the agent has to install and write.
Adjacent guides
Keep reading
AI Web UI Generation: What Actually Runs Between Your Prompt and the UI
Inside the substrate. What spins up, how fast, what the agent can actually do with it.
AI App Builder for Non-Developers
What the no-code path looks like end to end, and where it bumps into limits.
AI Mobile App Builder
Same architecture, different output: HTML/CSS/JS that runs in a phone browser.