Ship your first vibe-coded app today, in one afternoon

Step 1. Type one sentence. Specific beats clever.

The prompt box is the entire first page. There is no project setup ahead of it. The thing that separates apps that ship today from apps that drag into next week is the shape of that first sentence. Generic prompts produce generic apps. Specific prompts produce something you would actually use.

Compare these two openers. Both work. One ships tonight, one wanders for an hour.

The second prompt has scope (one screen), inputs (a slider), persistence (localStorage), and a view (a small chart). That is enough constraint that the model can finish the file. The first prompt has none of that, so the model invents constraints, and you spend the next forty minutes correcting choices you never wanted to make.

Step 2. Watch the HTML stream into the preview

This is the part most write-ups skip past because they are used to a build-and-wait loop. In Quick mode there is no build. Claude Haiku streams the HTML, CSS, and JavaScript one character at a time straight into the preview iframe. You watch the page assemble itself. By the time the final closing tag is written, the app is already running on your screen, and it is already at a public URL.

That last frame is the part that surprises people. The URL you are looking at in the preview pane is not a localhost stub. It is the same URL anyone else can open. There is no separate share step, because there is nothing to deploy. The proxy that makes this work is small enough to read in one sitting, and it is in the next section.

Step 3. The anchor fact: where the live URL actually comes from

The reason you do not have to deploy anything is that the preview already lives on a public hostname. The mk0r site has a wildcard DNS record on *.mk0r.com pointing at the load balancer, and a Node-runtime proxy in front of it that rewrites any subdomain request to the corresponding E2B sandbox. The whole proxy is 104 lines. The line that does the work is line 68, and it looks exactly like this:

// line 8
//   <vmId>.mk0r.com      ->  3000-<vmId>.e2b.app  (https)

// line 68
target.hostname = `3000-${hit.sub}.e2b.app`;

The honest constraint is the sandbox lifespan. It is one hour by default, set in one line at the top of src/core/e2b.ts:

const E2B_TIMEOUT_MS = 3_600_000; // 1 hour

After an hour of idleness the sandbox is reclaimed. Each request extends the window, so a URL someone is actively poking at stays up. A URL nobody touches dies on schedule. For a first-day demo posted on a Twitter reply, the hour is plenty. If you want it to live forever, that is a separate, deliberate step (Pro plan, custom domain) and not a precondition to shipping anything today.

Step 4. The two paths that come after the first preview

Most tools front-load the choice between "quick demo" and "real codebase" and force you to pick before you have written a single sentence. mk0r flips that. You start in Quick mode by default. If Quick can hold your idea, you are done. If it cannot, you switch to VM mode and the same prompt becomes the seed for a real Vite + React + TypeScript project in a Linux sandbox.

For your first app today, default to Quick. Switch to VM only if you actually hit the wall (multiple screens, state that needs to outlive the file, or a feature Quick visibly cannot hold). Do not pre-emptively switch to VM because it sounds more serious; the seconds-to-render gap matters when your motivation is "ship tonight".

What you can honestly ship in an afternoon

The honest envelope is: one screen, one job, no shared backend. That is bigger than it sounds. Most apps people actually use day to day fit inside it. Pick one that scratches a real itch you have, not the most impressive thing you can think of. The first one is for proving the loop works for you.

• A unit converter for a hobby (climbing grades, brewing gravity, cycling watts to pace).
• A bedtime sleep slider that saves a number a day to localStorage and shows a chart of the last two weeks.
• A focus timer keyed to the length of one specific song you already like.
• A custom dice roller for a tabletop system you actually play.
• A configurator that outputs Tailwind classes, then copies them to the clipboard.
• A regex tester that highlights matches inline as you type.
• A one-screen reaction game you can hand a kid for ten minutes.
• A reading speed estimator on text you paste in.

None of those need a login, a database, or anyone else's account. All of them can be a working URL inside the hour. The ones that do not work in this shape (multi-user inboxes, collaborative whiteboards, anything with a real payment flow) are also worth building, just not the first thing you do this afternoon. Start with the one-screen version of the bigger idea and ship that.

What stops people, and how to skip past it

The thing that kills first-day shipping is almost never the build. It is the steps before and after the build. The before-build trap is opening five tools to compare them, reading two newsletters about "the right stack", and ending the afternoon with tabs but no app. The after-build trap is the deploy gauntlet: account, hosting, DNS, SSL, env vars. Quick mode skips the after-build trap entirely because there is no separate deploy. Your job is to skip the before-build trap by writing the sentence and pasting it into the box within the first five minutes of sitting down.

If you are reading this on your phone in line somewhere, that is actually a good place to do step one. You probably will not finish on a phone, but you will get the first preview and a URL you can send to one person. That alone breaks the pattern of "I'll build something this weekend" and gets the loop unstuck.