The No-Editor App Building Floor

The category sells the ceiling. The floor is more useful.

Read the homepages of any ten AI no-code tools and you will see the same shape of promise: build any app, in minutes, without writing code. The ceiling. It is a wide promise on purpose, because the audience the page is fighting for is everyone with an idea.

That copy is useless if you are the person standing at the beginning of the flow, deciding whether to commit to a no-editor path at all. The question that decides commit is the floor: if I take this seriously and never open a code editor, what is the minimum thing I will end up holding when the session is done? Is it a screenshot of a mockup? A vendor-locked artifact? A real codebase someone could fork? An app that has a real database row when it claims to?

The floor is a more honest description of a tool than the ceiling because it does not ask the reader to trust ambitious framing. It asks the reader to look at what is already wired in, before any prompt fires.

What is wired in before turn one

The system prompt that scopes the agent on every new mk0r session is one paragraph and lives at line 184 of src/core/e2b.ts. Verbatim:

"You are an expert app builder inside an E2B sandbox with a Vite
+ React + TypeScript + Tailwind CSS v4 project at /app. The dev
server is running on port 5173 with HMR. You have Playwright
MCP for browser testing. Read your CLAUDE.md files for detailed
workflow, coding standards, and memory instructions."

That one paragraph is the floor of the stack. Vite, React, TypeScript, Tailwind v4, HMR, and a Playwright-driven browser attached to the same sandbox. None of it is mk0r-specific syntax. None of it is a proprietary export format. If you never open an editor, that is still the stack the agent is writing into, and if you outgrow the no-editor path you take the repo and you go.

The four backing services come from src/core/service-provisioning.ts. The provisionServices function on line 346 walks PostHog, Resend, Neon, and GitHub in order, collects credentials, and buildEnvFileContent on line 393 writes them into /app/.env before the first user turn arrives. The agent is told (in the project CLAUDE.md) to read /app/.envfor pre-provisioned services before asking the user for any API keys. So when you type “add email signup” on turn two, that is one prompt, not five.

The GitHub org the repo gets created under is hard-coded as GITHUB_ORG = "m13v" on line 52 of the same file. The repo URL lands in /app/.env on turn zero. Your first prompt commits to that repo automatically.

The verification loop is part of the floor

The reason the floor goes higher than the category implies is that the agent checks its own work in a real browser before handing control back. The five steps are quoted in the in-VM CLAUDE.md at src/core/vm-claude-md.ts lines 278 to 283:

1. Navigate to http://localhost:5173 via Playwright MCP.
2. Take a snapshot to verify the DOM rendered correctly.
3. Check browser_console_messages for runtime errors.
4. If the page is blank, verify the component is imported in App.tsx.
5. Do not report completion until the browser shows the expected result.

Most one-shot AI app makers stop at step zero, ship the diff, and trust that the next page load will render. mk0r ships the diff, opens the page, looks at it, reads the console, and only hands control back if the render matched intent. From a no-editor reader's point of view that is the difference between “the AI wrote some HTML” and “the AI wrote some HTML and verified it on a DOM”. That second thing is what the floor includes.

Where the floor stops

The point of writing about the floor honestly is to also write about where it ends. Four edges of the floor matter for a no-editor user.

• Interaction state. The snapshot is a DOM check at one moment in time. The agent does not click every button to see what state the app enters next. A bug that only surfaces after three clicks slips through.
• Backend writes. The agent confirms the UI rendered, not that the POST to Resend, Neon, or Stripe actually wrote a row. A green toast is not a green database.
• The six-turn anonymous gate. ANON_TURN_LIMIT = 6 on line 23 of src/app/api/chat/route.ts and the gate fires on line 197. Once you cross it you sign in to keep iterating. Six is enough for a single-screen shipped app, but you should know about it before you commit the first three turns to a vague prompt.
• The idle pause. E2B_TIMEOUT_MS = 3_600_000 on line 33 of src/core/e2b.ts. After one hour of inactivity the sandbox is paused. Your work survives byte-exact and reconnecting is automatic, but a non-coder coming back two hours later who sees the preview spinner needs to know that is normal.

A coder reading this catches the first two on instinct. A no-coder needs to be told. That is fine. The point of writing the floor down is to remove the surprise.

The floor versus the no-code category

The honest comparison is not feature-for-feature against Bubble or Glide. Those tools have years of polish in places mk0r does not (drag-drop precision, library size, native mobile output paths). The honest comparison is on the floor specifically.

Most platforms in the AI no-code category give you a floor inside their runtime: their database, their visual canvas, their renderer. The thing the agent produces lives there. If you leave the platform, you export to a format that is not quite a real codebase, or you start over. The floor is high on guardrails and low on portability.

mk0r's no-editor floor is the inverse. The output is a standard Vite + React + TypeScript project. The dev server is a real Vite dev server. The browser checking the work is a real Chromium driven by Playwright. The repo lives at github.com/m13v/<your-app> the moment service provisioning finishes on turn zero. You can clone it and open VS Code on it the same day. The trade is the inverse: more portable, less of the drag-drop polish.

Practical floor: what to actually do in your six turns

Six anonymous turns is not a lot if you spend them wandering. It is plenty if you commit to a shape. A pattern that works for the no-editor reader who has never used the product:

• Turn one. One short noun-phrase sentence describing what the app is. “A flashcard deck for Spanish verbs.” The agent will scaffold the screen and ship a draft. Resist the urge to pack five ideas into the first sentence.
• Turns two and three. Layout fixes. “Make the cards bigger.” “Move the deck-switcher to the top.” These are the cheapest, fastest changes the agent makes.
• Turn four. One real feature. “Add a button that saves my deck to the database.” This is where the pre-provisioned Neon connection earns its place, and where the agent goes from writing UI to writing wiring.
• Turn five. The copy and the polish. “Replace the placeholder text.” “Pick a real accent color.”
• Turn six. Look at the GitHub repo URL that has been in your /app/.env since turn zero, and decide whether you want to keep going past the gate.

Six turns is the floor of effort that produces a screen worth sharing. The ceiling, with a paid account and a longer session, is wherever you take it.