A pricing proposal is read more like a website than a document. Channel options for sending one, and where private-link HTML sits between a PDF attachment and an esignature tool.
Figma is designed for collaboration, so the share link shows comments, version history, and the frames you parked. Channel options for a client-facing preview, and where private-link hosting fits.
The format you pick for an internal review is a category-signaling choice. When the team starts shipping HTML links instead of .pptx attachments, the room reads it before the content opens.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.
Interactive dashboards lose their interactivity in PDF, screenshot, and screen recording. The trade-off, and where private-link hosting fits between handoff and full deployment.
The proposal goes out Tuesday morning. The client opens it on the train, taps to expand the timeline, taps again to see the case study you referenced. By Wednesday it's been forwarded to two other stakeholders, scrolled, partially read, partially skimmed. By Friday someone replies with three questions.
That whole arc is the proposal at work — not the moment of signature, the days of reading that come before it.
The container shapes how those days go.
PDF attachment. Designed for archive and print. Page breaks, fixed layout, opens the same on every device. Strong shape for the leave-behind after sign-off and for the lawyer's scan before signing. Less natural for the read-through phase: scrolling a paginated PDF on a phone shrinks the type, the bracket-priced scope tables don't reflow, the case-study link is a flat URL the client has to copy out.
Google Docs or Notion shared doc. Designed for collaborative working documents. Comments rail, suggestion mode, share settings — the framing is let's work on this together, not here's the offer. The Google/Notion chrome appears before the content. Works fine for proposals that genuinely are collaborative; less for the ones that are meant to land as a finished offer.
PandaDoc / Proposify / DocuSign with proposal builder. Designed for the esignature workflow. The client signs into the vendor's portal to read and sign. Strong shape when the proposal is the contract and the signature is the next action; adds friction earlier in the cycle, when the client is still deciding whether to engage at all.
Long email body with the proposal inline. Designed for short messages. Tables, headings, and footnotes render unevenly between Gmail, Outlook, and Apple Mail. Long emails get clipped by Gmail's Message truncated link, which puts the price below the fold for half the recipients.
Self-contained HTML at a private link. Designed for delivering a finished interactive document the client opens once. The proposal lives at a URL the freelancer controls, reads the same on phone and laptop, supports the small interactivity that proposals benefit from — collapsible scope sections, hover for case study details, an embedded walkthrough or testimonial.
A pricing proposal does a few things at once: it explains the work, lists the price, references past work as proof, lays out the timeline. Each of those reads differently when the container can do more than a static page.
None of these are blockers in a PDF. They're small interactions that compound across the read-through phase.
A freelancer is selling judgment, taste, and reliability — alongside the work itself. The proposal is the first long-form piece of writing the client reads from them; how the proposal arrives is part of how the freelancer is read.
A PDF attachment reads as here's the offer in the format my last twenty clients also got. Fine when the freelancer is already pre-sold; muted when they're competing against two other freelancers who already shipped websites for their previous clients.
An HTML link on the freelancer's own domain reads as I treat my own deliverables the way I'll treat yours. Same content, different frame around it.
The frame doesn't sell the proposal — the proposal sells the proposal. The frame just lowers the bar for the proposal to land.
Try a proposal as a private link before the next pitch — drop the HTML, get the URL, walk through the client experience on your own phone first. Free, no card, the file self-destructs after 7 days.
For freelancers already using a design tool or a notebook-to-HTML workflow, the build is mostly content-first:
For freelancers building proposals in dedicated tools (Bonsai, HoneyBook, the proposal feature in Notion), the same shape applies — the proposal still lands as an HTML page; the private link layer just controls the URL the client opens.
Solo plan ($4.99/mo) keeps the proposal link permanent (no self-destruct) and removes the footer — useful when you want the URL to live in the client's inbox until they sign. Password protection ships free on every account, no upgrade needed.
The private link path is for the read-through phase. It doesn't replace the esignature tool — when the proposal is also the contract and the client clicks Sign Here, the right shape is still PandaDoc, Proposify, DocuSign, or whatever the contract workflow uses.
A reasonable split for most freelance engagements:
The link is one stage of the cycle, not the whole cycle. The point is that the read-through stage has different needs than the archive, and the channel can match.