How to Share an AI Prototype with Stakeholders (Without a Developer)

Start with the shortest safe link

Use the sharing or publishing action already in your AI tool when it gives the right people the right access. Use Birta when the prototype can run as a static website and you want a separate, stable address an agent can update; if the review is not for everyone, ask the agent to put a password on the site. If the prototype needs accounts, a database, server code or private keys, keep it where those run.

"Without a developer" describes the first three paths. It is not a promise that every prototype can skip engineering: the software decides that boundary, not the tool that generated it.

Define the review before choosing the link

A stakeholder needs to decide something about one version. Before sending anything, write down four things:

1. The decision: what should they approve, reject or compare?
2. The path: which one or two actions should they try?
3. The boundary: what is real, what is mocked, what is deliberately absent?
4. The response: where do notes go, and by when?

A useful message is concrete:

Please try creating one project and changing its due date. The data is sample data and nothing is saved after refresh. Reply in the product channel by Thursday with the first point where the flow feels unclear.

That stops a prototype from being judged as if every visible control were finished. When the stakeholder is a client, the same message has three moments, and asking a client for feedback on a draft has a copy-ready version of each.

Keep one source of truth for the version under review. A new temporary link after every correction makes comments ambiguous. The remark-collecting loop is the sixth website prompt: send the version link, then have the agent read the numbered threads and fix them in the same draft. If you are weighing a client portal instead, Softr alternatives sorts out when the deliverable is a portal.

Use the path already built into the current tool

The named builders already publish or share work. Check the native option before exporting anything.

Native is not a lesser answer. Bolt keeps an in-progress site restricted to invited people, Claude Team and Enterprise sharing stays inside the organization, v0 shares the generation conversation with controlled permissions. Those beat a public site when the review touches internal strategy, unreleased designs or customer information.

Move a project only to solve a real problem: a separate address, a different ownership model, or an agent-led publication loop.

Check whether Birta fits

Birta is a fit only when all three statements are true.

The review is public, or a password is enough

Birta sites are public by default. For a review that should not be, ask the agent to put a password on the site: whoever has the link and the password gets in. A password is shared rather than per person, so a review that needs named accounts stays with the builder's restricted sharing.

The prototype can run as static browser files

A suitable prototype becomes index.html plus styles, browser JavaScript, images and fonts. Navigation, tabs, filters, a local calculator and sample charts all run in the visitor's browser.

It is not static when the project itself must keep any of these running:

• sign-in or access rules;
• a database or private customer records;
• server routes or background jobs;
• a private API key;
• persistent application state owned by the project.

The same builder produces both kinds. Ask what must keep running after the finished browser files exist; the static-site-versus-application guide owns the full test, and the hosting decision guide is the wider version.

Publication requires index.html at the site root, and the site has to fit your plan's project space. PDF, video and audio are not served as site assets, so link to them elsewhere.

An agent can reach the source

Birta publishes connection guides for Claude, ChatGPT, Codex and Cursor, and the available actions depend on the client and account. OpenAI says full ChatGPT MCP write support is a beta for eligible Business, Enterprise and Edu workspaces, so check that the workspace exposes the actions. A local file-capable agent builds and checks the site, then publishes the folder directly.

There is no importer for a v0, Bolt or Lovable URL and none planned. Birta's agent, like any web-capable agent, reads a public page by its URL and works from the rendered HTML, CSS and images. That is enough for a static screen and not enough for a prototype whose behaviour is the thing under review.

So a Claude Artifact can be translated from the source already in the conversation. v0, Bolt or Lovable need an explicit source handoff: Git sync, a code download or another supported export. Bolt documents a ZIP download and Lovable documents Git sync and codebase export. If you cannot get the source into a supported agent, use the native link.

Publish through the agent that has the source

1. Step 1ClassifyConfirm that the review is public or fine behind a password, and the prototype can become static browser files.
2. Step 2Hand offKeep a Claude Artifact in its source chat, or export the project to a file-capable agent through the builder's supported path.
3. Step 3PrepareBuild and test the static output before publication; do not hide missing runtime behavior.
4. Step 4PublishUse the current Birta connection guide, open the public result, and send one bounded review request.

Step 1: Classify before moving anything

Ask the agent to inspect the project without changing it:

Inspect this prototype without changing it.

Decide whether its review flow can run as a public static website after a
production build. Check for authentication, private data, databases, server
routes, background work, private environment variables, persistent state, and
assets that will not be present in the built output.

End with one of these answers:
- Ready for a public static prototype, followed by the exact build command and
  output folder.
- Keep on its current application platform, followed by the blocking features.

Do not publish anything yet.

The useful result is the list of blockers. A prototype that only looks static can still call a database or expose a secret.

Step 2: Put the source in the right agent

Take the shortest route the source tool supports:

• Claude Artifact: stay in the conversation that owns the selected version and follow the same-chat publication guide.
• v0: use its project/GitHub workflow to put the source where a file-capable agent can build it.
• Bolt: download the project or use its source-control path.
• Lovable: use Git sync or the codebase download, then check every dependency on Lovable Cloud, Supabase or another runtime. The Lovable hosting guide covers which ones disqualify a project.

If the handoff becomes more work than the review is worth, go back to native sharing.

Step 3: Prepare the public version

Create a review build, not an accidental production promise:

• remove credentials and replace private records with clearly fictional data;
• make unavailable actions visibly disabled or label them as mocked;
• keep the one scenario stakeholders need to test prominent;
• run the real production build and open its output locally;
• confirm the output root has index.html and every asset it references.

Birta receives finished browser files. It does not run your source build.

Step 4: Publish and send the review

Open the matching Birta connection guide for the agent that has the source, publish the verified output to one project, then open the returned public URL in a private window.

If Birta rejects the package, the current live version stays active. Fix what it reports and publish again. Send the URL with the decision, the test path, the boundary and the response deadline you defined earlier.

Keep one stakeholder link current

Later publications to the same project keep its public address, so you can fix a confusing label without starting a second review thread.

The edit path depends on how the site was made:

• A Claude Artifact written as ordinary site files uses the draft-and-preview loop in its deploy guide.
• A project published from a separate build goes back to its source: ask the agent for the change, rebuild, test, publish that output to the same project.

Birta's browser file tools do not rebuild a project whose live site came from separately built sources, because changing generated files would be erased by the next build.

The last ten published versions stay available as rollback targets. If a review change is wrong, restore one rather than reconstructing it.

Once the prototype becomes the real site, building a site without a builder picks it up, through review rounds and on to your own domain.

Check the public result before sending it

Use the URL as a stakeholder would:

1. Open it in a private window, so your session cannot hide a missing file.
2. Check the requested path on a phone-sized viewport and a desktop.
3. Use every control in that path, and reload once to expose in-memory state.
4. Confirm every image, font, icon and external link loads.
5. Search the page and files for real personal data, credentials, private URLs and internal comments.
6. Label sample data and mocked actions in the interface, not only in your message.
7. Put the decision and the feedback deadline beside the URL.

If any confidential material remains, stop.

Treat visits as attention, not approval

Birta shows aggregate visitor totals for a published project. That tells you the page received traffic. It cannot tell you a named stakeholder opened it, followed the path, understood it or approved it.

Ask for an explicit reply, or record the decision in the team's normal system. To distinguish clicks, destination visits and recipient-specific access, use what a shared link can actually prove.

Frequently asked questions