How to share a prototype or MVP (without deploying it)

You asked Claude (or v0, or ChatGPT) for a clickable prototype of your app idea, and it gave you a folder: an index.html, a couple more pages, some images. It works when you open it on your machine. Now you want a few people to click through it and tell you what they think — and the obvious move, deploying it to Vercel or Netlify, feels like a lot of ceremony for "look at this thing I made."

Deploying vs. sharing — they’re different jobs

A deploy platform’s job is to run an app: build it, serve its backend, scale it, give it a production domain. That’s the right tool when there’s code that has to run on a server. But a clickable prototype usually has no server — it’s front-end files pretending to be an app. For that, the job isn’t deploying, it’s sharing: getting it in front of the right people and hearing back.

One way to hold it: Netlify and Vercel are for running apps; a sharing tool is for showing them. If the thing already runs by opening an HTML file, a deploy pipeline is solving a problem you don’t have yet.

What a sharing tool gives you that a deploy doesn’t

Push a prototype to Netlify and you get a public URL — and that’s about it. The things you actually want when collecting feedback aren’t in the box:

• Control over who opens it. A password, a list of invited people, or email-verified access — not just "anyone with the URL, indexed by Google."
• Feedback on the prototype itself. Comments reviewers leave in place, or a quick poll to settle a direction.
• Knowing it landed. View counts, who opened it, and an email the moment someone does.
• No build, no dashboard. Drag the folder in, get a link. Drag a new version in to update it.

On Shareable, you drop the whole folder (or a .zip) — theindex.html plus its images, CSS, and JS — and get exactly that link. Or ask your AI to publish it for you from the chat.

What runs in a shared prototype

Files are served raw, with no sandbox, so the prototype behaves the way it does locally: interactive scripts, click handlers, page transitions, multi-page navigation, and bundled assets all work. It can even call a backend you already have — a fetch() to an existing API, or a form that posts to a Google Apps Script — because that call runs from the viewer’s browser, same as anywhere. And to get answers back from testers, the prototype can send responses to Shareable with a <form data-shareable> or one Shareable.submit() call — you read them in your dashboard, no backend needed.

When you actually need Vercel or Netlify

The moment your prototype needs its own server, it’s become an app. Move to a deploy platform when you need:

• Server-side code — your own API routes, or server-side rendering.
• A database your app reads from, or real user accounts for your app’s users.
• A build step — a framework build, a bundler, environment-variable secrets.
• A production domain on a pipeline, with previews per branch.

Until then, you’re sharing a front-end, and a link beats a deploy.

Frequently asked questions