Guide

AI app demos shareable: when the demo IS the app, not a recording

The pages that currently win this topic almost all point at the same shape of tool: capture your screen, annotate the steps, share a link to a player that walks the visitor through what your app would have done. The visitor watches a recording. mk0r picks a different shape and calls it the same word. The link is the running software. The recipient interacts with the app, not a video of the app. The proof fits in two files, and one of them is a directory listing.

Matthew Diakonov, Written with AI

Published April 28, 20267 min read

Two artifacts that share one word

Type the phrase into a browser and the first page of results is dominated by tools whose entire job is recording. They capture screens, sequence the captured frames into walkthroughs, attach tooltips and clickable hotspots, and produce a hosted player you can drop into a sales email. The pitch is good and the tools are good at their job. The thing they are not is software you can run.

The mk0r pitch starts in a different place. The artifact you build is not a marketing object. It is a Vite + React dev server inside a sandbox, listening on a port, accepting requests, returning HTML and JSON. The shareable URL is an alias for that dev server. There is no step where the running app is converted into a different format and handed to the visitor as a recording. The demo and the app are the same object.

Both shapes call themselves a shareable AI app demo. Both ship a link. The link looks roughly the same. The difference shows up the moment the recipient tries to do something the original recorder did not script.

What the same word points at, side by side

Same prompt to your friend. Same goal: hey, look at what I built. Different artifact behind the link.

What the recipient is actually opening

You build the app somewhere, then open a recording tool, capture the screens you want, drag the hotspots into the right places, write the tooltip copy, and publish a player at a vendor URL. Your friend taps the link. They land in a video player or click-through framework. The chrome around the content tells them which vendor hosts the recording. They press play, watch the steps, follow the cursor where the recorder put it. They cannot type into a form to change what the demo shows. They cannot deep-link to a route the recording did not capture. They cannot hit an API. The artifact is a story about the software.

Watch only, no input changes
Vendor chrome around the content
Routes that were not recorded are not reachable
Recording goes stale when the underlying app changes

The directory listing that is the actual proof

You can usually tell which shape a builder picked by reading the API directory. Tools that ship recording-style demos have endpoints for rendering, exporting, screen capture, and snapshot storage. Tools that ship live-software demos do not, because they do not produce a separate object to render. The mk0r appmaker repo is the second kind. The src/app/api/ directory has 18 route folders. Below is the full list, copy-pasted from a directory listing.

src/app/api/
├── analytics/
├── auth/
├── auth-debug/
├── billing/
├── book-call/
├── chat/
├── claude/
├── cookie-bridge/
├── guide-chat/
├── health/
├── newsletter/
├── projects/
├── publish/
├── transcribe/
├── vm/
├── vm-logs/
├── waitlist/
└── webhooks/

Read it slowly. Look for the recording layer. There is no /api/render-demo. There is no /api/record. There is no /api/export, no /api/screenshot, no /api/walkthrough, no /api/snapshot. The word chat is the agent loop, claude is the model bridge, vm and vm-logs are sandbox introspection, publish is the custom-domain flow. None of these produce a demo artifact. They drive a live system.

The actual share mechanism is one Next.js middleware file at src/proxy.ts. It is 47 lines including imports and the export config. The work happens in a function called proxy() that rewrites the request hostname from <vmId>.mk0r.com to 3000-<vmId>.e2b.app. The path, the query string, the HTTP method, and the body all pass through unchanged. That is why the demo behaves like software: the recipient is talking to a real dev server, with a hostname swap as the only middleware in the way.

“Number of routes in src/app/api/ that produce a recorded demo artifact. The shareable URL points at the live dev server inside an E2B sandbox; there is no second object.”

src/app/api/ directory listing in the appmaker repo

Verbs the recipient gets, and verbs they do not

The clearest way to feel the difference is to look at what the person on the other end of the link can actually do. The list below comes from running through both shapes with a friend who had no accounts on either platform.

Verbs that work on the live-software demo

Type into a form, see the response the AI wrote
Paste a route after the slash, land on that screen
curl an /api endpoint, get JSON back
Drive the page with query params (?theme=dark, ?invite=abc)
Open the link tomorrow, see the latest version
Open the link on a phone, no install, no signup

Verbs that only work on a recording-style demo

Pause halfway through and replay the previous step
Click a tooltip the recorder added on top of the app
Trigger a guided walkthrough that auto-advances

The first list is the affordance of running software. The second is the affordance of a recording. They are not better-or-worse, they are different products. Which one you want depends on whether the recipient is supposed to interact or supposed to watch.

What happens when your friend taps the link

The trace below is what the request does on a live-software demo. On a recording-style demo, the trace stops at the vendor's player.

Recipient taps <vmId>.mk0r.com on their phone

Note that none of the boxes in this diagram is a recording vendor, a player, an embed, or a content delivery network for static assets. The first hop after the load balancer is the sandbox itself. The recipient is talking to your dev server, with TLS and a hostname rewrite as the only things between them.

Tools the keyword usually surfaces (none of them ship live software)

For context, here is the rough field of tools you tend to see when searching this phrase. They are good at what they do, and they are all the recording shape. Listed without endorsement, just to establish that the entire ecosystem points one way and mk0r points the other.

SupademoStorylaneDemosmithGuideflowScribeSynthesiaNavatticWalnutDemoboostReprise

The thing every name in that strip has in common: the artifact you ship is a recording, hosted by them, played in their chrome. mk0r's artifact is the running app, hosted in your sandbox, rendered in the recipient's normal browser. Both shapes are legitimate. The keyword does not tell you which one a tool ships, which is why this page exists.

A small thing I tried that made the difference obvious

Earlier this week I built a tiny coffee-shop finder as a test, and shared the URL with two friends. Friend A opened it on a phone, tapped a city, saw the list, tapped a shop, saw the detail. Normal stuff. Then friend B, who is more curious, asked if the search box worked with weird input. They typed ');DROP TABLE shops;--. The page handled it: no error, just zero results, because the AI had used a parameterized query. I had not asked for that and had not noticed. The interaction was real, so the bug-or-non-bug was real.

Then I asked the agent to add a sort-by-rating button. About forty seconds later it landed. Both friends reloaded the same link. The new button was there. Nobody re-recorded a walkthrough. Nobody re-uploaded an export. The link was current because the link was the app.

That is the kind of moment that does not show up on a marketing page about shareable demos. You only feel the difference once a curious friend pokes the link in a way the original tutorial did not script.

The honest trade-offs of skipping the recording layer

Pretending this shape is universally better would be silly. There are real costs.

The recipient is hitting your live dev server. If the build breaks, the link breaks too. There is no recorded version that lags behind the bug. A recording-style demo, by contrast, is frozen, which is exactly what you want for a sales pitch where every viewing has to look the same.

The link has no auth. Anyone with the URL can hit any route the AI built, including any /api endpoints. The privacy boundary is the unguessability of a 15 to 30 character vmId. For a demo with friends or a public toy, this is fine. For anything that touches private data, you tell the agent to put auth inside the app, or run the publish flow at src/app/api/publish/route.ts to map a custom domain in front of the sandbox and put a real edge between the visitor and the dev server.

Cold starts exist. After roughly an hour of inactivity (the E2B_TIMEOUT_MS constant on line 33 of src/core/e2b.ts) the sandbox pauses. The next click on the link wakes it back up. A recording-style demo has no cold start because there is nothing to wake. If first-tap latency on a stale link matters more than everything else, the recording shape wins.

Want to feel the difference yourself?

Hop on a quick call. We will build a live-software demo together, copy the link, and poke it from a phone the way a friend would.

Frequently asked questions

When somebody says shareable AI app demo, what do they usually mean?

Most of the time they mean a video, screenshot tour, or click-through that you record AFTER the software exists. The popular tools in this category (Supademo, Storylane, Guideflow, Demosmith, Scribe) all share the same shape: capture the screen, annotate the steps, generate a link to a player that walks the visitor through what your app would have done. The visitor does not interact with software. They watch a recording of someone else interacting with software. mk0r picks a different shape and calls it the same word, which is the source of the confusion.

What does mk0r mean by demo, then?

The running application. When you build something on mk0r, the agent runs a Vite + React dev server inside an E2B sandbox, and the URL the visitor opens is a wildcard subdomain of the form https://<vmId>.mk0r.com that the middleware in src/proxy.ts rewrites to that dev server. Tap the link, you are not watching a video, you are loading the app. Type into the form, the app processes the input. Click a button, the app responds. There is no recording layer because there is no recording step.

Where is the proof that there is no recording step?

The src/app/api/ directory in the appmaker repo. It contains 18 route folders (analytics, auth, auth-debug, billing, book-call, chat, claude, cookie-bridge, guide-chat, health, newsletter, projects, publish, transcribe, vm, vm-logs, waitlist, webhooks). None of them generate, render, or store a demo artifact. There is no /api/render-demo, no /api/record, no /api/export, no /api/screenshot. The only object that plays the role of demo in this codebase is the live URL the proxy serves. If you grep the source for the strings record, screencast, capture, or export and follow the matches, every one of them is about VM lifecycle (logs, debugging, restart), not about producing a demo file.

Why does the recording-vs-software difference matter to me?

Three reasons that show up the moment a real person opens the link. First, in a recording you cannot change the input. The demo plays the same path every time. In a software demo, the visitor types their own input and sees the actual response. Second, in a recording you cannot deep-link past the home view. The recipient lands wherever the recorder started. With mk0r, the proxy preserves the path verbatim, so the URL plus /any/route works. Third, a recording rots the moment the underlying app changes. You ship a fix, the recording still shows the bug. mk0r's link points at the live app, so the next change is in the demo at the speed of a page reload.

How does the recipient know it is the running app and not a recording?

Three things give it away in under thirty seconds. They paste the URL plus /api/whatever-the-agent-built into curl and get a JSON response, which a recording cannot produce. They paste the URL plus a route that did not exist when you copied the link (because you just told the agent to add it) and the new route loads, because the link points at the live dev server. They open the network tab and see requests going to a unique <vmId>.mk0r.com host, not to a content delivery network owned by a recording vendor. None of these tests work on a recorded walkthrough.

Is a recording-style demo ever the right answer?

Yes, and this is not a knock on those tools. Recordings are the right shape when the audience cannot tolerate any environment difference (a buyer who needs to see exactly what staging does), when the app needs an account or paid data the visitor does not have, or when you want a forty second skim that ends with a call to action. mk0r is a different shape: it works when the audience IS supposed to interact, when no signup is the point, and when the iteration loop needs to be fast (you tweak the prompt, the link is current). Pick the shape that fits the audience.

Does the link still work tomorrow if I close my laptop now?

Yes. The E2B sandbox is created with `{ onTimeout: 'pause', autoResume: true }` (line 309 of src/core/e2b.ts). When the timeout window of 1 hour (E2B_TIMEOUT_MS = 3_600_000 on line 33) elapses without activity, the sandbox is paused, not destroyed: RAM is serialized, disk image is kept. The vmId is persisted in Firestore under the app_sessions collection. When the recipient opens the link, E2B sees the inbound request to the paused sandbox, resumes it, and the dev server picks up where it left off. The first request after a long pause has a cold start; subsequent requests are normal latency.

Can I share two different demos at once, with different URLs, to different people?

Yes. Each session gets its own vmId, and the wildcard subdomain proxy serves any vmId that matches the regex /^[a-z0-9]{15,30}$/ on line 15 of src/proxy.ts. There is no per-link database lookup, no quota check, no allowlist. If you start three sessions you have three URLs, each routing to its own E2B sandbox, each behaving independently. A recipient on demo A cannot affect demo B because the proxy rewrites to a different upstream host. The cost of provisioning the next demo is whatever it costs to boot another sandbox (a few seconds when the prewarm pool has a slot ready, longer otherwise), which is why the keyword phrase is plural.

What about screen recording for things that need to look polished, like a launch tweet?

If you want a video, record one. mk0r gives you something a screen recorder can capture: the running app at a public URL on a phone-friendly subdomain. Open the link on whichever device feels most like your audience, run a screen recorder over it, and the resulting video is a recording of the live software. The point of this guide is that the live software exists FIRST, and the recording is downstream of that. Most of the tools competing for this topic invert the order: they have you build a recording, and the live software is somebody else's problem.

How do I confirm the shareable demo really is the live app and not a snapshot, in one minute?

Ask the agent to add a unique time-stamped string to the home page (`add the text 2026-04-28-test to the header`). Wait for the change to land. Open the link in an incognito window. If you see the new string, the demo is the live app. Now ask the agent to remove it. Reload the same incognito window. If the string is gone, you are looking at the live build. A recording would not update on reload. A static export would not update without a redeploy step. The link being live is what makes mk0r's plural demos behave like plural demos rather than plural copies of one frozen artifact.