The normal delivery ritual is finish, then send — and every revision mints a new URL and another 'ignore my last email'. If your AI tool can publish and then update in place, the link can go out first and stay correct. Including when that's a bad idea.
The standard way to deliver a piece of work is: finish it, then send it.
Everything in the tooling assumes it. You build, you export, you upload, you paste a URL into an email. Revise, and the sequence runs again — new export, new upload, new URL, new email that begins "ignore my last one, use this instead."
Three revisions in, your client's inbox holds four links, three of them dead, and no reliable way to tell which is which. And you have spent the entire build unable to show anything, because there was nothing to send until there was everything to send.
That constraint came from the tooling, not from the work.
It's not a habit anyone chose. It's the shape of the tools.
Most drag-and-drop hosts treat every upload as a new thing: a new deploy, a new project, a new address. That's a perfectly reasonable design for publishing — each release is distinct, and you may well want the old one to stay up. It's a poor fit for delivering, where "the current state of the thing I'm making for you" needs one stable address for weeks.
Given tools that behave that way, waiting until the end is the correct strategy. You send once because sending is expensive: every send costs a new URL and an apology.
Change the property and the strategy stops making sense.
If updating replaces the contents at the same address, the link stops being a snapshot of the work and becomes a place where the work lives.
Concretely, that means:
The mechanic underneath is unglamorous: the URL points at a slot, publishing writes the first version into it, and updating swaps the contents while keeping the address. On miinideck the password, expiry and title survive the replacement, and each update is kept as a numbered version rather than obliterating what came before — so "always current" doesn't have to mean "no history".
Plenty of people already do a version of this manually. Build, upload, replace, done. It works, and it's fine.
What changes with an assistant connected over MCP is where the loop ends. Without a connector, the loop ends with a file sitting on your disk and a small chore attached to it — open the dashboard, find the page, upload the replacement. Small enough to skip when you're busy. Which means the live link drifts behind the real work, and drift is exactly the failure this whole approach exists to prevent.
With the connector, the assistant publishes the page, can list what it has published, and can replace the contents of one it published earlier. The iteration ends at the live link. Nobody has to remember anything.
Two honest constraints:
The size ceiling. The replacement HTML travels as text through the connector, which caps it around 100 KB in practice. Single-page work is usually far under. Anything heavier — a bundle, a page with large inlined images — should go as bytes via the CLI or the uploader. The link stays the same; only the pipe is different. Worth knowing up front rather than discovering mid-iteration.
It publishes as you. The tools are authenticated, so an assistant can only touch pages belonging to your account. That's a deliberate limit, and it's the reason there's no anonymous key to hand around.
One address for the work: publish once, replace the contents as it evolves, and the link you sent on day one is still the right link in week six.
This is a practice with a domain, not a rule.
Send it finished when the first impression is the deliverable. A pitch deck landing in a stranger's inbox. A proposal being read alongside two competitors'. A portfolio piece. These get one read, and roughness reads as sloppiness rather than as progress.
Send it finished when the reader can't tell a draft from a decision. Some stakeholders treat anything on a link as a commitment. If a placeholder number will end up in a board summary, the fact that you labelled it a draft won't save you.
Don't use a live link as a record. Always-current is a feature during iteration and a liability afterwards. If a specific state needs to be citable — the version they approved, the one attached to an invoice — publish it separately so it stops moving.
The practice suits work where the recipient is a collaborator in the outcome: the client who'll be using the dashboard, the stakeholder whose corrections you actually want, the colleague reviewing a prototype. It suits AI-built work particularly well, because that work iterates in hours rather than weeks, and the gap between "roughly right" and "right" is a conversation rather than a rebuild.
The reason to care isn't the saved upload. It's that a stable address changes what a link is to the person holding it.
A link that might be superseded is something you check once and then wait to be told about. A link that's reliably current is something people return to — which is the difference between a client who sees your work at the end and a client who watches it happen. The second one gives better feedback, asks for changes earlier, and is markedly harder to surprise at the invoice stage.
None of that requires the link to be clever. It requires it to hold still.
Related: collecting feedback on a prototype without booking a meeting, getting comments back into your AI tool, and — for the flip side, when a platform's own share link turns out not to hold still at all — what happens when an artifact can't be republished.
ChatGPT Sites hosts what you build and gives you access controls — owner only, named workspace members, the whole workspace, or the public internet. There's no rung for one outside client. Here's the shape of that gap and the route round it.
It looked like a URL. You sent it. It doesn't exist — and never did. Why models produce link-shaped text when you ask them to share something, how to spot it in one second, and what actually has to happen for a real link to exist.
The agent handed you a URL and said it's live. It probably is. What it didn't tell you is who can open it, how long it lasts, whether the address is guessable, and what happens to it when you revise — four defaults chosen for you, none of them announced.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.