miinideckmiinideck
PricingUse casesBlog
Sign in
Sharing AI-built apps

How to share an AI-built page with a client (and make it actually client-ready first)

The AI tool built the page. Sending it to a client is a second job: stripping the construction site, making it read as yours, and putting it behind a private link. A practical checklist for turning AI output into a client-ready handoff.

By miinideck·September 2, 2026·7 min read
TL;DR
  • Sending an AI-built page to a client is a second, separate job from building it. The output is functional; it is not yet client-ready. The gap is branding, privacy, and polish — and the AI tool's own share button skips all three.
  • Three moves close the gap: strip the construction site (badges, prompt history, the tool's domain), make the page read as yours (custom domain, white-label, a clean title), and put it somewhere private by default (unguessable link, optional password and expiry).
  • If the page has a real backend — a login, a database it writes to — that part is a deploy job for Vercel or Netlify. A private link owns the self-contained front-end slice, which is most of what a client actually needs to review.

The page works. You described it, the AI tool built it, the form submits and the charts redraw. So you reach for the share button right there in the editor, paste the URL into an email, and send it to the client.

That is the moment the work gets undone. Building the page was one craft job. Handing it off is a different one — and the share button does none of it. What lands in the client's inbox is a link on someone else's domain, often a "made with" badge in the corner, sometimes a prompt to sign in to a tool they have never heard of. The client does not open a finished deliverable. They open the workshop, with your work somewhere inside it.

The build is the part that feels like the job. The handoff is the part the client actually experiences — and the gap between "the page works" and "the page reads as mine" is exactly the gap nobody's tool fills for you. Three moves close it.

Move one: strip the construction site

An AI builder's export carries traces of where it came from. Before anything else, find and remove them.

Look for a watermark or "built with" badge baked into the page corner — many tools inline one into the HTML export. Check the browser tab title; it often defaults to the tool's name or a generic "Untitled," and a client notices a tab that says the wrong thing. Scan for any visible URLs, footer credits, or "edit this page" affordances that only make sense to you, the builder.

Then there's the link itself. The tool's native share URL frequently does two things you don't want in front of a client: it drags the whole prompt-and-iteration history along, and it sometimes requires the viewer to have an account on that platform just to see the page properly. A hesitant client who hits a sign-in wall on an unfamiliar tool often just closes the tab. The fix is to stop sharing from inside the tool and instead export the page as a self-contained .html file or a .zip bundle — HTML, CSS, JavaScript, and assets in one package that renders anywhere, with no account required and no editor attached.

This applies whatever built it. The same export-then-share path works for a Cursor build, a Lovable app, a v0 page, or a Bolt project — the construction site differs, the strip-it-down step is the same.

Move two: make it read as yours

Stripping the badges removes the wrong signals. This move adds the right ones — so the page reads as something from your studio, not from a tool you happened to use.

Two details carry most of that weight, and both are things the client clocks before reading a word. The first is the browser tab and the domain. A tab that says your project name and a link on deliverables.yourstudio.com tell the client this was made for me, deliberately — where a builder's subdomain reads as a sandbox preview you dashed off. Serving the page from your own custom domain is the single biggest jump in how finished the handoff feels.

The second is everything around the page the client never asked to see: the wrapper chrome, and whatever shows if the link later expires. White-labeling that surface so it carries your name instead of the host's removes the last "this was made with a tool" tell. The bar is simple — nothing between the client clicking the link and reading your work should name a third party. On miinideck, the custom domain and white-label both sit on the Studio plan; they exist precisely for this client-facing case.

Export your AI-built page as one HTML file or a ZIP, drop it in, and get back a private link with no AI-tool branding on it. The client opens it in any browser — no account, no sign-in wall.

Make a client-ready link (no signup)

Move three: private by default, controlled on top

A page for one named client should not be reachable by anyone who isn't that client. This is where the reflex to push it to a public host goes wrong: public hosting is built for reach, and reach is the opposite of a single-client handoff.

A private link inverts that. The page sits behind an unguessable URL, hidden from search by default — you send the link, the client opens it, and no one stumbles onto it. From there you add exactly the control the engagement needs:

  • Password when the page carries figures, names, or pricing that shouldn't travel past the person you sent it to. Send the password through a separate channel than the link. Free on every plan.
  • Expiry when the review has a window — a proposal good for two weeks, a draft that shouldn't outlive the round of feedback. Free on every plan.
  • One current version. When you ship a revision, replace the file behind the same link so there is a single source of truth, and the client never re-opens a stale draft by accident.

The same private-link slot covers the adjacent client jobs too — a proofing link for design review, or a link you don't have to babysit or take down later.

The honest boundary: when it's not a file

One check before you treat the page as a private link. Does the page run a real backend — a login, a database it writes to, server-side routes, a payment step? If yes, that part is not a file and a static link won't serve it. It's a deploy job, and Vercel or Netlify are the right tools for it; no static host replaces them.

But notice what the client usually needs to review: the interface, the flow, whether the thing looks and feels right. That's the front-end, and the front-end is self-contained. Export a static version of it, share that for the proofing round, and keep the live backend build for a real deploy once the design is signed off. You get a clean, private review link now without pretending a file is a server.

The handoff, end to end

Put together, the client-ready path is short: export the working page as a self-contained file, strip the badges and the tool's domain, serve it from your custom domain with a white-labeled wrapper, and lock it to your client with a private link plus a password or expiry where the content warrants it.

The build is the part that feels like the work. The handoff is the part the client actually experiences — and it's the part the share button quietly skips. Spend the extra few minutes on it, and what reaches your client reads as a finished deliverable from you, with no sign that an AI tool was ever in the room. If you're still deciding where AI-built pages should live in general, the host-by-reach breakdown and the AI-artifact hosting guide cover the wider map.

More in Sharing AI-built apps

ChatGPT Sites usage limit reached: which Sites can move out, and which can't

Hit a ChatGPT Sites usage limit? Your Sites aren't gone. Here's how to tell the ones that are just pages, which travel, from the ones that need Sites underneath them.

September 26, 2026·8 min read

Where to host an AI-built page: private link vs public deploy vs the tool's own share (2026)

You built a page with an AI tool. Three places it can live — the builder's own share URL, a public deploy, or a private link — and a clear way to decide between them based on whether the page has a backend and who is supposed to reach it.

August 12, 2026·6 min read

Your ChatGPT Site is built. Your client isn't in your workspace. (2026)

ChatGPT Sites can now invite a named viewer from outside your workspace — but they have to sign in with the account you invited. If your client won't, here's the shape of what's left and the route round it.

July 31, 2026·9 min read

Send your own private link.

miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.

Try it free →See pricing
miinideck

HTML files, finally as links — for AI builders, agencies, and consultants. Default-noindex, default-private, default-yours.

Product

  • Pricing
  • Use cases
  • Try it free

Resources

  • Blog
  • Free tools
  • Featured on
  • Report abuse

Legal

  • Privacy
  • Terms
Listed onmiinideck listed on Product Huntmiinideck listed on Faziermiinideck listed on TheSaaSDirmiinideck listed on AIToolHuntmiinideck listed on LaunchNest
© 2026 miinideckMade for people who don't want their work indexed.