Guide

Rapid prototyping service, without the 8-week SOW

Every agency page that ranks for this topic sells the same shape: a kickoff call, a discovery workshop, a sprint, a handoff, 1 to 8 weeks. That still exists, and sometimes it is the right call. The thing nobody tells you is that the same phrase now also means a runtime that fits in a browser tab and rewinds one prompt at a time.

m
mk0r engineering
9 min
4.9from Founders and PMs who came here off an agency quote
Pre-baked VM boots in about 2.5s
Every prompt is a real git commit in /app
Rewind the prototype with historyStack + activeIndex

The agency shape, and the runtime shape

Read ten pages about this topic and you will see one pattern on repeat: “Our rapid prototyping service delivers working software in 2 to 8 weeks.” There is a discovery workshop, a sprint cadence, a designer, a PM, a review gate. The deliverable is a clickable prototype and sometimes code.

The runtime shape is different. You open a browser tab, type a prompt, and a Vite + React sandbox boots before you finish reading the placeholder. Each follow-up prompt is a git commit, each undo is a checkout, each preview is a real URL you can send to a colleague. Both shapes ship prototypes. Only one of them lets you change your mind on Wednesday without a status email.

No kickoff call
No SOW
No Figma handoff
No Jira
No weekly status doc
No designer-to-engineer translation
No retainer
No NDAs to start
No 'we'll circle back Thursday'
No discovery sprint
0sPre-baked VM boot
0Accounts required to start
0Git commit per prompt
0msHMR paint window

The anchor fact: every prompt is a git commit

The feature that makes this a usable prototyping service and not a demo is version control. Every iteration, from the first prompt to the last tweak, writes a real commit into the sandbox's /app repo. The SHA goes on a historyStack stored on the session doc, with an activeIndex pointer. Undo moves that pointer back one slot and applies the older tree. No diffing UI tricks, no virtual history. Real commits.

src/core/e2b.ts

You can verify this from inside the sandbox. Open the in-VM terminal, run git log --oneline, and you will see one entry per turn, authored by the session, back to the initial scaffold commit created in ensureSessionRepo when the session was first provisioned.

Undo is not a Ctrl-Z trick, it is a checkout

When you hit undo, the server looks up the previous SHA in historyStack[activeIndex - 1] and applies it by running git checkout <sha> -- . against the working tree, then committing the result as a new synthetic commit so the forward history stays linear. Redo does the mirror. Jump-to-SHA lets you time-travel to any commit in the stack by clicking a dot in the version timeline.

src/core/e2b.ts

Two timelines, side by side

To make the compression concrete, compare a typical agency plan against the runtime plan. Neither is inherently better; they are different products wearing the same phrase.

Same prompt: 'build a lead capture form with a 7-day streak counter'

Signed MSA, signed SOW, kickoff call. Designer produces Figma. PM schedules a sprint. Engineer implements in a fresh repo. QA runs a checklist. Final preview shared in week 3 or 4. Scope change requests take a follow-up ticket.

  • Elapsed time: 2 to 4 weeks
  • Round trips: a dozen emails and three calls
  • Rewind cost: a retro and a ticket
  • Artifact: Figma, repo, preview URL behind SSO

What actually boots when you land on the page

A rapid prototyping service is only “rapid” if it is already running when you arrive. The moment the landing page mounts, it pings a pool-top-up endpoint so the next user, which might be you, does not pay boot cost. The flow:

Claim path: prompt in, sandbox out

Browser mount
Prompt submit
Session UUID
Pool + VM
Warm sandbox claim
ACP session re-init
Vite + Chromium ready

The hub is the pool. A Firestore collection called vm_pool holds ready sandboxes tagged with the current spec hash. When you claim, a transaction atomically pops one, re-initializes the ACP bridge with your credentials, and hands back a live acpUrl. The cost of a cold boot only shows up when the pool is empty, and the cold boot is already ~2.5 seconds because the image is pre-baked.

The four-minute mental model

There are more moving parts than a marketing page needs to show. If you only remember four steps, remember these.

  1. Arrive

    Browser mounts. Session UUID in localStorage. Prewarm ping.

  2. Prompt

    Text goes to the ACP bridge. Claim pops a warm VM.

  3. Verify

    Agent opens localhost:5173 in Chromium via Playwright MCP.

  4. Commit

    historyStack grows by one. activeIndex moves to the new SHA.

  5. 5

    Share

    Preview URL is public. Send it before lunch.

Agency service vs. runtime service: the tradeoff table

The right answer depends on what you are shipping. A bespoke internal tool with integration into your SSO and your data warehouse will probably still want a human team. A lead-capture form, a calculator, a CRUD admin panel, a one-screen demo that needs to exist by Thursday, those belong in the runtime.

FeatureAgency engagementmk0r runtime
Time from yes to first preview URL1 to 4 weeksUnder 2 minutes
Cost to change direction mid-prototypeScope-change memoOne click, one prompt
Version control of the prototypeUsually, in a separate repoReal git commits in /app, per turn
Can the builder verify its own UI?Manual QA passYes, Playwright MCP snapshot loop
Account and onboardingMSA, SOW, SSO onboardingUUID in localStorage
External API calls from the prototypeWorks, once provisionedVM has normal egress, no CORS proxy needed
Best fitBespoke, integrated, regulatedThrowaway, validating, one-screen-to-ten-screen scope

An agency is still the right buy for long-tenured, integration-heavy work. For everything where the goal is 'does the idea survive being used for ten minutes,' the runtime is cheaper and faster.

Inside the sandbox terminal

An abridged session from inside the VM. The ACP bridge streams these events back to your browser as NDJSON; the terminal below is what they look like if you SSH into the pre-warmed image and run the same commands by hand.

sandbox / bash

The three numbers that decide whether this counts as “rapid”

Pulled from the running product, not a pitch deck. These are the numbers that make the difference between “AI demo” and “service you can actually use.”

0s
Cold boot from the pre-baked E2B template
0 min
Pool entry max age before cleanupStalePool recycles it
0
Git commit per prompt, appended to historyStack

When to pick runtime, when to pick agency, when to pick both

If the goal is to find out whether an idea survives being clicked by a real human, start with the runtime. The cheapest version of any prototype is the one that is live in fifteen minutes, because the dominant failure mode of prototyping is not shipping the prototype at all.

If the prototype needs to integrate with your SSO, your data warehouse, or a vendor's SDK that takes a week to get access to, an agency is the right move, or we can pair. Start in the runtime to validate the shape, then hand the commits to a team that knows your stack.

The hybrid path is the one most founders end up on. Draft in a browser tab, iterate with prompts, rewind freely, and only book a call when you have a prototype worth pointing at. That is the motion this page is built for.

Want a human to walk you through the historyStack?

Twenty minutes, a live sandbox, and a prototype you keep whether you buy or not.

Book a call

Frequently asked questions

What is a rapid prototyping service in 2026?

Historically it meant hiring an agency to spin up a working prototype in one to eight weeks. Today it can also mean a self-serve runtime: you type a prompt, a pre-baked sandbox boots in around 2.5 seconds, and a coding agent writes, runs, and verifies a Vite + React app in front of you. Both models still exist. What changed is that the runtime version fits in a browser tab and does not require a scope of work.

How is mk0r different from a traditional prototyping agency?

An agency sells hours. mk0r sells iterations. When you prompt, the Claude agent writes files into /app inside an E2B sandbox, runs `git commit -q -m '<turn message>'`, and pushes the resulting SHA onto a historyStack stored with your session. There is no kickoff call, no designer-to-engineer handoff, no retainer. If you need a human in the loop for scoping or a pilot, the call link at the bottom of this page is the shortcut.

How fast does the environment actually come up?

The E2B template (ID 2yi5lxazr1abcs2ew6h8) is pre-baked. npm install for Vite, React, TypeScript, Tailwind v4, @playwright/mcp@0.0.70, and @agentclientprotocol/claude-agent-acp@0.25.0 all happen at image build time, not at claim time. The landing page fires `fetch('/api/vm/prewarm', { method: 'POST' })` on mount so the pool tops up while you are still reading. Cold boot is roughly 2.5 seconds; claims from the warm pool are effectively instant.

Why does every iteration need to be a git commit?

Because prototyping is rewind-heavy. You try something, it is almost right, you want to back up one step without losing the sandbox. In the code, commitTurn shells out `git add -A && git commit -q -m '<msg>' && git rev-parse HEAD`, appends the SHA to historyStack, and moves activeIndex. undoTurn jumps activeIndex back one slot and applies that tree via `git checkout <sha> -- . && git commit --allow-empty`. The timeline is real; you can inspect it with `git log` inside the VM.

Can the agent check its own output, or does it just generate and hope?

It checks. Every sandbox ships with @playwright/mcp bound to the same Chromium running on the virtual display. After writing a file, the agent can call browser_navigate against http://localhost:5173, take a browser_snapshot, read the a11y tree, and confirm the error overlay is gone before handing the iteration back to you. Agencies iterate in Slack. The runtime iterates inside one turn.

What kind of prototype fits this format?

Anything you would have built in Vite: calculators, dashboards, lead forms, CRUD admin panels, marketing pages with interactive demos, internal tools, onboarding flows, data visualizations on top of a CSV, Stripe checkout mock-ups. The sandbox has Postgres client, ffmpeg, Chromium, Xvfb, and normal VM egress, so prototypes that need real API calls, a browser, or a database still work.

Do I have to sign up or talk to a salesperson first?

No. The landing page creates a session UUID with `crypto.randomUUID()` and stashes it in localStorage under `mk0r_session_key`. That key claims the sandbox. You can prototype, iterate, and get a shareable preview URL without an email address. If you want the prototype to persist across devices or hand it to a team, then you sign in; otherwise, the session itself is the account.

What happens if I do want a human on the call?

Book time through the call link at the bottom. Useful when you are evaluating the runtime for a team buy-in, want a walkthrough of the undo graph and publish path, or need help shaping a prompt that maps to something tricky like multi-user auth. A call is twenty minutes, the demo is live in a real sandbox, and you leave with a working prototype regardless of whether you buy anything.

Skip the SOW, start a prototype

Pre-baked VM, git-backed undo, Playwright-verified output. No signup, no kickoff call, no weekly status doc.

Open mk0r