I built Pay-to-Unlock for freelancers who are tired of sending final files before getting paid
Hey IH 👋
In May, I shipped one of the biggest updates to LinkVault so far.
The original idea was simple: help freelancers, agencies, and creators stop sending final files before getting paid.
This month, LinkVault evolved from secure file sharing into a more complete delivery and monetization platform.
What’s new:
- Stripe Pay-to-Unlock: clients can preview files, but only download after payment
- Pay-to-Unlock for Data Rooms: monetize entire folders or client spaces
- Client Portals: branded spaces for each client
- Approvals & Change Requests: clients can approve or request changes directly
- Contextual Comments: comments on PDF pages or video/audio timestamps
- Advanced Viewer Protection: extra protection against screenshots, printing, and inspection
- Client Timeline & Intent Score: see who viewed what and how interested they are
- Global Analytics: performance across all links and campaigns
- Custom branding, SMTP, email templates, and automatic email translation
- Larger file uploads and expanded API support
The goal is to make final file delivery safer, more professional, and monetizable.
I’d love feedback from other founders, freelancers, and agency owners:
Would you use something like this before sending final deliverables to clients?
Full changelog:
https://linkvault.biz/changelog/
Trending on Indie Hackers
This looks quite similar to MitFloww (https://www.mitfloww.com/), which also focuses on client review, approvals, comments, and secure file delivery workflows
You idea looks great though, best wishes!
Nice, looks great
Thank you!!
This is a really interesting direction.
I like the idea of moving the “trust boundary” closer to the actual delivery moment. A lot of freelancers get burned because the final handoff happens before payment, and after that they lose leverage completely.
The approvals/change requests piece also feels important. In my experience, a lot of client friction comes from unclear expectations around what is “done” vs. what is still a revision.
Do you see LinkVault mostly being used at the final delivery stage, or are people also using it earlier in the project as a client portal for approvals/checkpoints?
That’s a really sharp way to frame it: moving the trust boundary closer to the delivery moment.
Right now I see LinkVault’s strongest use case as final delivery, because that’s where the pain is most obvious: the work is done, the client wants access, and payment still needs to happen.
But I do think it naturally expands earlier into the project as a lightweight client portal for checkpoints, approvals, and revision clarity.
That “done vs revision” point is exactly why approvals and change requests felt important to add.
I’ve actually been exploring that side separately too with ChangeProof: making feedback, approvals, and change requests clearer before final delivery.
The broader goal is to reduce ambiguity around what was shown, what was approved, what changed, and when the final handoff should happen.
The "preview but don't send the file" pattern is solid — anyone who's ever
delivered work to a slow-paying client knows the exact 3am moment where you
realize you have zero leverage left.
One honest question from someone who can't actually use Stripe (Burkina Faso,
not a supported country — just hit this launching my own stuff): any plan for
non-Stripe payment rails? Paddle, Polar, Lemon Squeezy were also all
Stripe-backed when I checked recently, so there's a real gap for builders in
unsupported countries who'd otherwise be a perfect fit for the use case.
Smaller question: the Viewer Protection vs screenshots framing — is that
watermarking + overlay, or something stronger? Asking because anti-screenshot
is a feature clients often request but rarely trust, so I'm curious how you
scoped it.
Either way, data rooms + intent score is sharper than the bare "paid file
share" framing — feels like you've found the actual market.
This is incredibly useful feedback, thank you.
The Stripe limitation is a real point. Right now LinkVault is built around Stripe because it gives a reliable payment confirmation flow for automatic unlocks, but I’m aware that creates a gap for founders and freelancers in unsupported countries.
I’m looking at alternative rails, but I don’t want to add something unless it can support the same core requirement: payment confirmation needs to reliably trigger access unlock.
On viewer protection: I try to be careful with the wording. I don’t think any web viewer can honestly promise perfect screenshot prevention. The approach is layered deterrence: watermarking, overlays, anti-print, blur/focus-loss behaviour, DevTools detection, clipboard/text-selection controls, and viewer restrictions.
So the goal is not “impossible to capture.” It’s more: make unauthorized use harder, more attributable, and less casual.
And yes, I agree with you on data rooms + intent score. That’s starting to feel like the stronger market direction beyond just “paid file sharing.”
Appreciate you engaging with all of it.
From the other side of that Stripe gap — what worked for me was going merchant-of-record instead of integrating a processor myself. The platform owns the Stripe/PayPal side and just hands you a confirmation webhook to trigger the unlock off. Gumroad was the one that actually paid out to Burkina Faso (LS and Paddle didn't, for me), and its "Ping" webhook / Sales API is exactly the "payment confirmed → unlock" signal you're protecting. Totally different integration shape from embedding Stripe in your own flow, I know — but if covering unsupported-country sellers ever becomes worth it, an MoR layer might be the least painful way to keep that reliable signal without each user needing their own Stripe account.
Agree on the viewer side — "harder, more attributable, less casual" is the honest version; clients can smell anything that overpromises.
And data rooms + intent score is the wedge: knowing who's actually serious is the part people pay to keep.
Great question! A few things that work well:
Make sure your Google Business Profile is complete
Join niche communities where your customers hang out
Get listed in relevant directories — we actually just
launched a free one at SmallBusinessOwners .co if you
want to check it out
Hope that helps!
Thanks for the suggestions. Directories and niche communities definitely seem useful at this stage, especially for building early visibility and authority around the product.
Hey! Yes, I'd love to give you a fresh pair of eyes on LinkVault.
Since I've been building an invoicing product myself, I have a pretty clear view of where the payment-to-delivery flow can break.
Want me to run through it and send you notes by tomorrow?
Also - and I'll be direct here - I've noticed freelancers who solve delivery protection still struggle with the invoicing side before that moment. My tool handles that part. If your users ever ask for "the invoice piece," I'd love to explore a cross-promo or integration.
No pressure either way. The audit is on me regardless.
Where should I send my feedback?
Thanks, that would be really useful.
You’re right that invoicing and delivery protection sit very close together, but they solve slightly different parts of the workflow.
The way I currently think about it is:
invoice/payment request → payment confirmation → protected delivery/unlock
LinkVault is focused on the final handoff and access-control layer, but I can definitely see users asking for a cleaner invoicing piece before that.
Happy to take a look at your notes and also open to exploring cross-promo or integration if there’s a natural fit.
You can send feedback here or by email: [email protected]
I think the strongest part of the product is actually the emotional problem underneath it:
freelancers hate the moment where they’ve already delivered the work but still aren’t sure they’ll get paid.
That tension is very real.
One thing I’d watch carefully though is keeping the core value extremely obvious as more features get added.
Because “secure paid delivery” is immediately understandable, while approvals, portals, analytics, intent scoring, branding, APIs, etc. can start making the product feel much broader and more complex very quickly.
Personally, I’d probably keep anchoring the onboarding and messaging around that first core moment: “send work confidently before final payment.”
Totally agree, that’s a really good point.
The emotional problem is definitely the core of LinkVault: that uncomfortable moment when you’ve finished the work, sent the files, and you’re still waiting or hoping to get paid.
I’m trying to keep the main positioning focused on exactly that: secure paid delivery for freelancers and agencies.
The extra features like portals, approvals, analytics, branding, etc. are meant to support that workflow, but you’re right that they shouldn’t make the product feel too broad or harder to understand.
“Send work confidently before final payment” is actually a great way to frame it.
Thanks for the thoughtful feedback, this is super useful.
Out of curiosity, from your perspective, would you keep the homepage almost entirely focused on Pay-to-Unlock / secure paid delivery, and introduce the other features later in the onboarding?
Personally, yes — I’d probably keep the homepage heavily anchored around the core emotional problem first. “Get paid before clients access final files” is instantly understandable and emotionally clear. I think the extra features become much more valuable after users already trust the core workflow.
So instead of leading with everything at once, I’d probably introduce complexity progressively:
Otherwise there’s a small risk the product starts feeling like a broad “client workflow platform” instead of a sharp solution to a very painful freelancer problem.
The interesting thing is that the emotional clarity is already strong — so I’d personally protect that as much as possible.
That makes a lot of sense.
I think you’re right that the homepage should probably stay very sharp around the core moment: get paid before clients access final files.
The more I talk to freelancers, the more I see that the emotional trigger is not “I need more workflow features,” it’s “I don’t want to lose leverage at final delivery.”
So the extra features should probably support that journey rather than compete with it.
Really appreciate the way you framed this. “Protect the emotional clarity” is a good reminder.
Also noticed you help founders with QA and launch readiness. That feels very relevant for LinkVault, since any broken flow around payments/files would immediately hurt trust. I’d be open to your eye on the product if you’re still offering audits.
Appreciate that — and honestly I do think products like this live or die on trust clarity in the small moments.
Especially around:
type interactions.
Those are the places where small UX or flow issues can quietly create hesitation very quickly. I’d be happy to take a more structured look at the onboarding / delivery flow and put together focused feedback around trust, clarity, and friction points if that’d be useful.
That would be genuinely useful, thank you.
You’re exactly right about the small trust moments. For LinkVault, the product can’t just “work technically” — users need to understand at every step what is locked, what is unlocked, whether payment succeeded, and what the client can or can’t access.
The areas you mentioned are exactly the ones I’d love feedback on:
You can send feedback here, or if it’s easier, feel free to email me at [email protected]
Really appreciate the offer.
Took a deeper look at the onboarding flow and I think the biggest UX tension right now is that the product positioning and the actual onboarding flow feel slightly different emotionally. The positioning feels very much like: “get paid before clients access your work.” But the current setup flow sometimes feels closer to: “secure file sharing with optional monetization.”
For example, I could already upload files and generate secure links before connecting Stripe, so the payment-protection part felt slightly secondary instead of being the core workflow.
I also think the “small trust moments” matter a lot here:
users need to instantly understand what is protected, what the client can see, what’s locked/unlocked, and what happens after payment.
The good news is that the foundation already feels strong. The upload flow itself is surprisingly clean/lightweight, and the setup progression creates a good sense of momentum.
I’d be curious to see the actual client-side flow next, because I think that’s where trust clarity will matter even more.
This is extremely useful, thank you.
The distinction you made is exactly what I needed to hear: the public positioning says “get paid before clients access final files,” but parts of the onboarding still feel like “secure file sharing first, monetization later.”
That’s a real mismatch.
I think the product needs to make Pay-to-Unlock feel like the primary path from the start, not an optional feature users discover after uploading. Especially because the whole emotional promise depends on the user feeling: “my file is protected until payment happens.”
Your point about trust states is also spot on. I’m going to look closely at making the product much clearer around:
I agree the client-side flow is probably where this matters most. If the client experience feels confusing, the freelancer won’t trust it either.
Really appreciate the depth of this. This is exactly the kind of feedback I was hoping for.
One follow-up question: if you were redesigning the onboarding priority, would you make “create a paid delivery link” the default first flow, and keep normal secure sharing as a secondary option?
Honestly, yes — I’d probably make “paid delivery” the default emotional path from the very beginning. Not necessarily in a forced way technically, but in terms of how the product frames the workflow. Because right now the strongest value proposition is not: “share files securely.”
It’s: “I can send final work without losing leverage.”
That’s a much more emotionally charged problem.
So I think users should feel almost immediately that:
this is a payment-protected delivery workflow first,
and secure sharing/features/supporting tools second.
Then secondary flows like:
free sharing,
branding,
analytics,
portals,
API access,
etc.
can expand naturally after trust in the core workflow already exists.
The interesting thing is that the product already feels much stronger emotionally when viewed through that lens.
This comment was deleted 16 days ago.