Guides

Client deliverables without the client portal

If your agents produce client work as HTML — audits, strategy docs, RFCs, dashboards, campaign retrospectives — the cleanest handoff is one stable URL per deliverable, gated to the client's email domain, that anyone on their team can open without creating an account. Revisions republish to the same URL, so the link in their bookmarks is always current. And because the page is yours rather than an attachment lost on their mail server, you get the one thing attachments never give you: you know whether they read it.

That is what Send Artifact does. sendartifact.com/yourstudio/acme-growth-audit is the deliverable. There is no portal — nothing for the client to join, nothing for you to maintain. Just the link, its version history, its readership, and the client's notes, in one place.

Why is the deliverable handoff still broken?

The work changed faster than the handoff did. An agent can now produce a genuinely good interactive deliverable in an afternoon: a technical audit with expandable findings, a dashboard the client can filter, a retrospective with the charts inline instead of screenshotted. Ad agency Adspirer replaced deck-based client reporting with Claude-built interactive reports across 15 retainer clients and got reporting down to "5 minutes per client". Producing the deliverable is now the fast part.

Then it hits one of three defaults, and all three are bad.

Attach the file. An .html attachment renders as raw markup or gets stripped outright in Outlook, and even when it survives, it lands in a downloads folder with a timestamp for a name. When you revise, v2 goes out in a new thread, and now the client's inbox holds three files named some variation of "final." You also learn nothing: an attachment sends zero signal back about whether anyone opened it.

Invite the client into your tools. They won't come. A seven-person dev shop that builds RFCs and reports with AI hit exactly this wall — a client refused to sign up for the shop's internal tooling just to read the work, so the shop built its own bare-bones hosting for finished documents instead. It worked well enough that, as the founder put it on Show HN, "People we shared with kept asking how they could do the same, so we turned it into a product." The AI labs' native sharing has the same wall from the other side: it is shaped around their subscription, not your client. As one review of lab-native dashboard sharing put it, "A solo consultant on a Pro plan literally cannot share a live-data dashboard with anyone."

Build a client portal. Some firms conclude the answer is their own portal. Now you run authentication, password resets, permissions, uptime, and "I can't log in" support tickets — a software product with roughly one user per client. You billed for the audit; you are maintaining infrastructure.

What does the artifact link change?

The fourth option: publish the deliverable to a stable URL of its own. One link per deliverable, minted the moment your agent finishes the work, access-controlled from the first second, updated in place for as long as the engagement runs.

Everything downstream of production hangs off that one URL — who can open it, which version they see, whether they read it, and where their notes land. The rest of this guide walks those four, because they are the actual job of a handoff.

How do you keep it to just the client's team?

Every publish starts private — nobody but you can open it. You widen it deliberately: grant individual emails, or grant the client's whole domain so anyone @client.com can open it. Domain access means the deliverable follows the engagement rather than a recipient list you maintain by hand. When your contact forwards the link to their CFO — and she will — the CFO gets in too: a one-time email code proves the address, and a session persists after that. No password, no account, nothing to install.

That last part is a hard requirement, not a nicety. In the interviews behind our own product spec, a design partner set the bar at viewers getting in "without needing to login, kinda how Dropbox was when it launched." A client's willingness to read your work is a budget, and forced account creation spends all of it.

For fuzzier audiences there are looser modes — anyone with the link, or fully public, each optionally asking readers to state or verify an email before the page opens. Useful for a whitepaper or a case study. For a paid deliverable, gate to the domain and move on.

What happens when the deliverable changes?

Deliverables are drafts until suddenly they are not. You publish the draft audit Monday, address the client's notes Wednesday, ship the final Friday — same slug, same URL, three immutable versions. The client's bookmark always opens the current one. Old versions stay addressable, and rollback is one click if something goes out early. Nobody ever receives audit-final-v2-ACTUAL.html.

Version history also answers a question no attachment can: who saw which version.

That record earns its keep on calls. "We cut the migration section in v2 per your note" is checkable — the versions are there, and so is who read each one. If the client's engineer only ever opened the draft, you know to walk the final's changes before debating them.

Did the client actually read it?

This is the section most sharing setups skip, and it is the one that changes your week. The read signal replaces the "just checking if you had a chance to look at this" email:

• Views by day and by version, with distinct viewers counted
• Per-reader identity where the reader is known — and domain-gated readers are always known, because they verified their email to get in
• Active read time per reader: time the page was actually in front of them, not time the tab existed
• Max scroll depth per reader
• Bot and link-preview fetches filtered out, and your own views tagged separately, so the outside-reader numbers are clean

Concretely: the CFO opened the final version, spent 50 seconds, and stopped a third of the way down. Thursday's call now opens with a two-minute walkthrough of the findings, not "any thoughts?" Or the opposite: three people on the client side each spent eight minutes in the draft before anyone replied to your email — the silence was circulation, not disinterest. Either way, you stop guessing, and you stop writing the nudge email that makes both sides slightly worse at their jobs.

Where does client feedback land?

On the deliverable, anchored to the passage the client is reacting to — not in a fourth email thread paraphrasing "the part about attribution, maybe two-thirds down."

Readers can leave comments directly on the artifact. You review them and decide what happens next; nothing changes just because a client commented. When you decide a note is worth acting on, you point your agent at it: the agent pulls the open comments over the CLI — each arrives with the quoted passage that locates it — makes the edits you chose, republishes to the same URL, and replies to each resolved comment describing what changed. The client sees their note answered in place. You never retype feedback from an email thread into a prompt, and you stay in the approval seat the whole way.

When is this the wrong tool?

Hosting, to be clear, is free everywhere. Netlify Drop, GitHub Pages, or an S3 bucket will serve HTML at no cost, and if the deliverable is public and final — a published case study, a marketing page — they are fine. A signed SOW belongs in a PDF. And if your engagements genuinely revolve around two-way file exchange, invoicing, and support tickets, dedicated portal software is the honest answer; an artifact link does not do those jobs.

The artifact link covers the gap between those poles: finished work, a specific paying audience, revisions expected, and you needing to know it landed. The hosting was never the product. The product is what happens after the link is sent.

What does this look like in practice?

For an agent-driven practice, publishing is a pipeline step, not a chore. From any shell:

npx @sendartifact/cli publish ./audit --slug acme-growth-audit
npx @sendartifact/cli access acme-growth-audit --visibility guests --grant client.com

Your agent can run those same commands itself: the skill at sendartifact.com/skill.md teaches any coding agent the full flow, sign-in included. There is a web drop-zone too, when you would rather drag a folder. Artifacts are self-contained static HTML up to 25 MB — plenty for a deliverable with inline charts and interactivity.

Freelancers run the same loop before the engagement even starts: developers on HN describe keeping planning documents as artifacts and sending estimates straight from them. The estimate, the plan, and eventually the deliverable are the same kind of object at the same kind of URL, which is exactly how a small practice should want it.

End to end: the agent drafts the deliverable, you review it, publish — private by default — widen to the client's domain, and send one link in a two-line email. Every revision, read, and comment after that happens at the URL. No portal, on either side.

Questions: support@sendartifact.com.

Published 2026-08-27 · markdown twin at /guides/client-deliverables-without-the-portal.md · questions: support@sendartifact.com.