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. That is usually the fastest way to put a working prototype in front of stakeholders, and it avoids moving a project for no reason.

Use Birta when the prototype can run as a public static website and you want a separate, stable address that an agent can update. Do not use a public Birta site for confidential work. If the prototype needs its own accounts, database, server code, or private keys, keep it on a platform that runs those features and involve the appropriate technical owner before treating it as production.

“Without a developer” is a reasonable description of the first three sharing actions. 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 does not need “the prototype” in the abstract. They need to make a decision about a specific version. Before sending anything, write down four things:

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

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 sentence does more for the review than a polished URL alone. It tells stakeholders what to inspect and stops a prototype from being judged as if every visible control were finished product behavior.

The remark-collecting loop is the same work written as something to paste: the sixth website prompt sends the version link, then has the agent read the numbered threads and fix them in the same draft.

Keep one source of truth for the version under review. Sending a new temporary link after every correction makes comments ambiguous: a reviewer cannot tell whether a note refers to the current screen or yesterday's. A native project URL or one Birta project address avoids that problem when later updates keep the address stable.

Use the path already built into the current tool

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

Native is not a lesser answer. Bolt can keep an in-progress site restricted to invited people. Claude Team and Enterprise sharing stays inside the organization. v0 can share the generation conversation with controlled permissions. These paths can be better than a public site when the review includes internal strategy, unreleased designs, customer information, or proprietary source material.

Moving a project should solve a real problem: a separate address, a different ownership model, or an agent-led publication loop. “This other host also gives me a URL” is not enough reason on its own.

Check whether Birta fits

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

The review can be public

Birta sites are publicly accessible by default. There is no current Birta password or invite-only publishing path. A hard-to-guess address is not access control. If the prototype is confidential, use the builder's restricted sharing or another service designed for private review.

The prototype can run as static browser files

A suitable static prototype becomes index.html plus its styles, browser JavaScript, images, and fonts. It can include navigation, tabs, filters, a local calculator, sample charts, and other interactions that run in the visitor's browser.

It is not a static site 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 can create both kinds of result. A React interface is not automatically server-backed, and a visually simple prototype is not automatically static. Ask what must keep running after the finished browser files exist. The static-site-versus-application guide owns the full test. If you still cannot name what the builder produced, start with the broader hosting decision guide.

Birta's current publication checks require index.html at the site root. The whole site has to fit the space your plan gives one project: 25 MB on the free plan, 100 MB on Solo, 200 MB on Pro. On top of that, no single file may exceed 25 MB and a site may hold at most 2,000 files. PDF, video, and audio files are not served as site assets, so link to them at a suitable public location instead of assuming they will travel with the prototype.

An agent can reach the source

Birta currently publishes connection guides for Claude, ChatGPT, Codex, and Cursor products, but 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 on the web, with workspace controls. Do not assume that every ChatGPT account can write a Birta site; use the current guide only when the workspace exposes the required actions. A local file-capable agent takes a different path: it builds and checks the site, then publishes that folder directly.

Birta itself does not open somebody else's link. There is no importer for a v0, Bolt, or Lovable URL and none is planned, because a web-capable agent already fetches a public page and hands back the rendered HTML, CSS, and images.

Separate two cases before you pick a route, because a fetched page is not a project. What comes back from a URL is the rendered surface. That is enough for a static screen, and not enough for a prototype whose behavior is the thing under review.

For a compatible Claude Artifact, Claude can translate the source it already has in the conversation into a Birta draft. For v0, Bolt, or Lovable, moving outside the native host normally requires an explicit source handoff: Git sync, a code download, or another export supported by that tool. Bolt currently documents a ZIP download, and Lovable documents Git sync and codebase export. Those are manual transfer steps, not direct Birta integrations.

If you cannot get the source into a supported agent, use the native link. A fetched copy of the rendered page demonstrates the look, so do not send it as the prototype when reviewers have to judge how it behaves.

Publish through the agent that has the source

1. Step 1ClassifyConfirm that the review can be public 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 current 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, not a confident one-word answer. A prototype that only looks static can still call a database or expose a secret.

Step 2: Put the source in the right agent

Use the shortest route the source tool supports:

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

The point is not to turn a product manager into a Git operator. The handoff should leave the source and build with an agent that can run the necessary commands and explain a blocker. If the handoff becomes more work than the review is worth, return 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 that the output root contains index.html and every local asset it references.

For a separately built project, test this output before telling the agent to publish. Birta receives the finished browser files; it does not run the source build in its online chat tools.

Step 4: Publish and send the review

Choose the matching Birta connection guide for the agent that has the source. Create or select one project, publish the verified static output, then open the returned public URL in a private browser window.

If Birta rejects the package, the current live version remains active. Fix every reported problem in the source or build output and publish again. Do not move files around until the error disappears without understanding why they were missing.

Send the URL with the decision, test path, prototype boundary, and response request you defined earlier. A naked link makes the reviewer reverse-engineer the assignment.

Keep one stakeholder link current

Later publications to the same Birta project keep its public address. That lets you fix a confusing label or adjust the flow without starting a second review thread around a second URL.

The edit path depends on how the site was created:

• A compatible Claude Artifact written as ordinary site files can use the draft-and-preview loop described in its deploy guide.
• A v0, Bolt, Lovable, or other project published from a separate build must go back to its source. Ask the file-capable agent for the change, run the build, test the output, and publish that new output to the same Birta project.

Birta's browser-based file tools do not rebuild a project whose live site came from separately built sources. This is intentional: changing generated files without changing their source would make the next build erase the edit.

Birta normally exposes the last ten published versions as rollback targets. If a review change is wrong, restore an available earlier version instead of trying to reconstruct it. Treat ten as the current recovery window, not an unlimited archive.

Once the prototype stops being a prototype and becomes the real site, the job changes shape. Building a site without a builder picks it up from there, through review rounds on the draft 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 builder or Birta 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 state that only existed in memory.
4. Confirm that every image, font, icon, and external link loads from the public page.
5. Search the page and browser files for real personal data, credentials, private URLs, prompt fragments, and internal comments.
6. Label sample data and mocked actions in the interface, not only in the message that carries the link.
7. Put the decision and feedback deadline beside the URL.

If any confidential material remains, stop. A technically working public link is the wrong outcome for a private review.

Treat visits as attention, not approval

Birta can show aggregate visitor totals over time for a published project. That can tell you the public page received measured traffic after distribution. It cannot tell you that a named stakeholder opened it, followed the intended path, understood the idea, or approved it.

Ask for an explicit reply or record the real decision in the team's normal system. If you need to distinguish clicks, destination visits, campaign labels, and recipient-specific access, use the full guide to what a shared link can actually prove.

Frequently asked questions