How to share a deliverable without a portal login

2026-05-24·10 min readclient-deliveryportals

By Sankalp Agarwal · Founder, Anchorify

The direct answer to how to share a deliverable without a portal login: publish the file as a public URL and send the link. No portal config, no client account required. The rest of this guide covers why portals exist, where they break down for finished deliverables, and the specific workflow for replacing the portal step with a URL.

Why client portals exist (and when they make sense)

Client portals were built to centralize the admin layer of a creative-services relationship: contract signing, invoice payment, questionnaires, and file history all in one place. Dubsado (Starter at $335/yr), HoneyBook (Starter at $29/month), and Copilot all built portals for ongoing client relationships where multiple admin touchpoints justify asking a client to create credentials.

That use case is real. A wedding photographer managing 40 clients a year, each with a contract, payment plan, and three rounds of gallery delivery, benefits from a portal. So does a bookkeeper with 15 monthly retainers. The portal earns its login step when the client touches it more than twice.

The problem is not the portal itself. The problem is using a login-gated portal for the one specific step that does not need it: handing off a finished deliverable to a client who just needs to read the file.

What the portal login step kills for one-time deliverables

The portal login wall fails in three predictable ways when the recipient's only job is to read a finished file.

One-time recipients do not create accounts. A client at the end of a six-week brand identity engagement has no incentive to create portal credentials for a one-time file view. They see the "create account or sign in" prompt, decide it is not worth the effort, and email back asking for the PDF. The portal step added friction at exactly the moment the engagement should have felt finished.

Portal UX is optimized for admin, not reading. The portal homepage surfaces contracts, invoices, outstanding forms, and payment history. The deliverable the client actually cares about is in a file tab, behind a navigation layer built for project management. A client who just wants to read the final strategy deck has to figure out where it lives in an interface they have never used before.

Account creation aversion is not a client education problem. A motion designer on r/MotionDesign captured the decision point plainly: "I realized if I asked them to 'create an account,' they would never use it." (reddit.com) This is not something you can solve by writing clearer welcome emails. It is a workflow problem to design around.

Amy Pearson, a Dubsado Systems Strategist who has written detailed comparisons between CRM tools, notes that even minor portal friction compounds: "In HoneyBook, clients typically interact through the client portal experience (and some clients don't love having to log in just to pay an invoice)." (amysgould.com) If login friction affects something as motivated as paying an invoice, it definitely affects something as passive as reading a deliverable.

The pattern holds across the CRM category. Dubsado's own onboarding guide advises portal admins to include "clear login instructions" in welcome emails, which is a tacit acknowledgment that the login step creates enough confusion to require explicit guidance. (dubsado.com)

When sending a URL beats using a portal

A public URL beats a portal for deliverables when the recipient is a one-time or project-based client who has no reason to maintain portal credentials.

Situation Portal URL
Final deliverable, one-time client Poor fit Strong fit
Ongoing retainer with recurring admin tasks Strong fit Partial
Multiple reviewers with no portal seats Poor fit Strong fit
Content that gets revised multiple times Poor fit Strong fit
Recipient resistant to creating accounts Poor fit Strong fit
Contract or e-signature needed Strong fit Not applicable
Analytics: did the client read it? Varies by tool Strong fit
Delivery to non-technical recipient Poor fit Strong fit

The key column is the "multiple reviewers" row. A deliverable shared via a portal requires every reviewer to have portal credentials. A URL can be forwarded to anyone on the client's team without any configuration on your end.

The workflow for sharing a deliverable without a portal

The workflow has four steps: write the file as markdown, publish it to a public URL, send the link, and update in place when revisions land.

Step 1: Write the deliverable as a markdown file. Most deliverables that end up in portals (strategy decks, brand briefs, SEO reports, proposals) are already written in some text format. Markdown adds no friction if you are writing in a text editor or exporting from a tool that supports it. If your workflow produces a PDF, a clean alternative is to write the narrative sections in markdown and reference any visual attachments by URL.

Step 2: Publish to a URL. Run:

anchorify deliverable.md --slug acme-brand-brief

The command prints one line: https://anchorify.io/you/acme-brand-brief. That is the deliverable URL. No portal configuration, no client-side account setup, no welcome email instructions required.

Step 3: Send the link. Paste the URL into your email, your Dubsado workflow email step, or wherever you communicate with the client. The recipient clicks the link and the document opens in their browser. There is no login prompt.

Step 4: Update in place when revisions land. When the client sends feedback and you revise the file, re-run the same command:

anchorify deliverable.md --slug acme-brand-brief

The URL does not change. The client's saved email link and any bookmark still work. The updated content is live immediately. This update-in-place behavior is what makes the URL approach genuinely better than emailing a revised PDF: you do not manage a thread of "v2", "v3-final", "v3-final-REVISED" attachments.

Full setup takes under two minutes. See the getting started guide. The full command surface is in the CLI reference.

Trade-offs of skipping the portal

Skipping the portal means giving up contracts, e-signatures, invoicing, and workflow automation. These stay in your CRM, not in the URL.

Feature URL approach Portal approach
Recipient login required No Yes
Contracts and e-signatures No Yes (Dubsado, HoneyBook, all plans)
Invoicing and payment collection No Yes (Dubsado, HoneyBook, all plans)
Workflow automation No Dubsado Premier ($525/yr) only
Analytics: view count, scroll depth Yes Varies
Version history per file Yes Varies
Comments from recipient Yes Varies
Access control Password or members-only Portal login
Recipient account required No Yes
Update content at same URL Yes Varies

The honest framing: these two approaches are not mutually exclusive. Most users who adopt the URL workflow continue to run Dubsado or HoneyBook for contracts and invoicing. The portal handles the admin layer; the URL handles the deliverable layer. The two tools never need to know about each other.

For the full comparison of how this plays out specifically with Dubsado, see Anchorify vs Dubsado portal. If you work with consulting clients and deliver monthly reports, the consulting delivery workflow has more detail on fitting this into a retainer cadence.

Analytics, comments, and version history with a URL

A public URL for a deliverable can carry analytics, threaded comments, and version snapshots, features that portal delivery typically omits for the file-sharing step.

Analytics. Every share on Anchorify records view count, time-on-document, and scroll engagement per visitor, without asking the recipient to install anything or grant any permissions. You know whether the client read the deliverable before you follow up. See per-share analytics for the data available.

Comments. Recipients can comment on the document without creating an Anchorify account: anonymous read access is the default, and Google sign-in is only required to post a comment. This keeps the feedback loop open without adding an account-creation step. See comments and reactions.

Version history. Every re-publish creates a snapshot of the previous version. If a client asks "what changed from the version I reviewed last week," you have a diff. For a monthly SEO report or any deliverable that evolves across revision rounds, the history is automatic. See version history.

None of these require the recipient to do anything. The analytics are passive, the comments are optional, and the version history is automatic. This is the difference between the portal model (where the client must log in for any of these to work) and the URL model (where the recipient's only action is clicking a link).

Frequently Asked Questions

These are the questions that come up most often when agencies and freelancers switch from portal-based delivery to URL-based delivery.

Do clients need an account to open a URL shared with Anchorify?

No. The read side of Anchorify requires no account on the recipient's part. Anyone with the URL opens the document in their browser. The only step that requires a Google sign-in is posting a comment, and that is optional. If you want to restrict who can read the document, you can add a password or set visibility to members-only via visibility controls. Neither restriction requires the recipient to create an Anchorify account.

What is a good alternative to Dubsado's client portal for deliverable sharing?

For the deliverable-sharing step specifically, the alternative to client portal systems like Dubsado's is publishing finished files as public URLs. Anchorify is free for the core sharing workflow. Keep Dubsado for contracts, invoices, and scheduler. The two tools operate in different parts of the workflow and do not conflict. For a full feature comparison, see Anchorify vs Dubsado portal. For HoneyBook users, a similar comparison is available at Anchorify vs HoneyBook.

Can I password-protect a deliverable URL so it is not fully public?

Yes. Anchorify supports per-share passwords. Run anchorify deliverable.md --slug acme-brief to publish, then set a password from the dashboard or via the CLI. The URL remains stable; recipients enter the password once and the document opens. See visibility controls for the full set of options including members-only visibility for sharing with specific users only.

How do I update a deliverable after sending the link?

Re-run the same publish command with the same slug: anchorify revised-deliverable.md --slug acme-brand-brief. The URL stays the same, the content updates immediately. The client's saved link still works. Anchorify also keeps a version snapshot of the previous content, so if a client asks what changed, you have a record. See version history.

Can I still use Dubsado or HoneyBook alongside URL-based delivery?

Yes, and most users do. Keep your CRM for the admin layer: contracts, e-signatures, invoice payment, automated workflows, and scheduler. Use Anchorify for the deliverable layer: finished files, proposals, briefs, reports, and decks that clients need to read. The two tools never need to integrate. You publish a URL on Anchorify, paste it into your Dubsado email step or wherever you communicate with clients, and the workflow continues as normal. The portal handles the admin; the URL handles the file.

Sources

Anchorify turns any markdown file into a shareable URL with one command. The recipient clicks a link; no account required, no portal setup, no permission dialog. Free during beta. Sign in at anchorify.io to publish your first deliverable.

Last updated: 2026-05-24