How do you share a Bolt.new app with someone who does not use Bolt?

Download the project, build it to static output, and host that output at a public URL. The recipient opens a normal link in any browser and needs no account with the tool you built it in.

Can you host a Bolt.new project without a deploy integration?

Yes. The build output of a front-end project is just files, so any static host will serve it. Uploading the build folder as a zip is usually faster than wiring up a deployment integration for a one-off review.

Why does the shared app show a blank page?

The most common cause is an absolute asset path: the build expects to live at the domain root and the host serves it from a subpath. Setting the base path in your bundler config to a relative value before building usually fixes it.

How do teammates leave feedback on the app?

Host the build on a platform with on-page commenting, then share a single link. Teammates click the element they are talking about and pin the note there, instead of describing its location in a chat message.

Does re-uploading a new build lose earlier comments?

Not on Undraft. Each upload becomes a new version of the same project and keeps its own pinned comments, so earlier review rounds stay readable instead of being overwritten.

How to Share a Bolt.new App With Your Team

Bolt.new can scaffold and run a complete application inside a browser tab, which is remarkable and also entirely private to you. Getting it in front of five teammates is a different job from building it. This guide covers turning a Bolt.new project into a link your team can open, click through, and mark up.

The Problem

The generated app runs in an environment your teammates do not have. Sharing it means one of three bad options.

Screenshots. Fast to send, impossible to interact with. Nobody catches that the form does not submit.
A screen recording. Better, but reviewers cannot try the thing they are curious about, and their feedback arrives as timestamps.
“Clone the repo and run it.” Technically complete, practically a wall. Half your reviewers are not going to install Node to look at a layout.

There is a fourth failure that is subtler and more common: you do deploy it somewhere, the link works, and the feedback still arrives as a chat thread full of sentences like “the card on the right.” The link solved distribution. It did nothing for the feedback.

A Bolt.new front end compiles down to static files. Once you have those files, hosting is trivial and the reviewer experience is a normal web page.

1. Get the project locally

Download the project or push it to GitHub, then pull it down. You are looking for a standard project folder with package.json.

2. Build it

npm install
npm run build

Most Bolt.new front ends are Vite-based, so the output lands in dist/. Open dist/index.html locally first — if it works, it will work hosted.

3. Fix the asset paths if the page comes up blank

This is the one snag worth knowing in advance. Bundlers default to absolute asset paths, which assume the site is served from the root of a domain. If the page is served from a subpath, every /assets/... request 404s and you get a white screen with console errors.

For Vite, set the base to relative in vite.config.js and rebuild:

export default { base: './' }

Now the build works wherever it is served from.

Zip the dist/ folder and upload it. You get a URL that anyone can open — no account, no install, fully interactive.

On Undraft, that URL is also where the feedback goes. A reviewer clicks the element they mean and pins a comment to it, so “the card on the right” stops being a sentence you have to decode and becomes a marker on the card.

A generated app often carries things that will derail a review:

Live API keys in the front end. Anything in a client bundle is public. Rotate or remove before sharing a build outside your team.
Backend-dependent flows. If a route needs a server that is not there, either mock it or tell reviewers to skip it. An unexplained error state absorbs the entire review.
Placeholder content that reads as a decision. Lorem ipsum is understood. A fake price of $4,999 will get argued about for twenty minutes.

Say what is real and what is scaffolding in the same message as the link. It costs one sentence and saves a review round.

Examples

Before

Build a dashboard in Bolt.new.
Post three screenshots in the team channel.
Two people react with a thumbs-up, one asks whether the filters work.
You record a video showing the filters.
Someone notices in the video that the empty state is broken.
You fix it and post more screenshots.

The bug was found by luck, from a video, on the second pass.

After

Build the project and upload dist/.
Share one link: “interactive, data is fake, please try the filters.”
Three reviewers click through it themselves. One finds the empty state in the first minute and pins a comment on it.
You fix, rebuild, re-upload to the same link.
Reviewers reopen the link and resolve their comments.

The bug was found because someone could actually click.

Summary

Build and upload the output folder — a static build is the format every reviewer can open, with no install and no account.
Check asset paths before you share — a relative base path is the difference between a working link and a blank page with console errors.
Avoid review-by-screenshot — interaction is where prototype bugs surface, and a static image hides every one of them.

Next: the direct guide to share an HTML file, and how reviewers comment on a webpage once it is live.