Stop losing deals in the gap between "sounds good" and getting paid
The slowest part of freelancing was never the work. It was the gap between a client saying "sounds good" and money actually landing in my account.
The pattern never changed. Good call, then "send me a proposal", then I spend an evening on a PDF and hear nothing back. No idea if anyone even opened it. When someone did say yes, the deal still had to survive printing, signing, scanning, and a separate invoice in a third tool. The work was never the slow part. The gap between yes and money was.
So for the last two months I built Pactiamo. A proposal or contract becomes one link. The client opens it, reads, signs in the browser, and pays through your own Stripe, PayPal, or bank link. No account for them to create, and I never touch the money. AI writes the first draft, there is a legal check that flags the clauses working against you, and view tracking plus reminders do the chasing so you stop refreshing your inbox.
Two honest things about how I built it.
What I'm glad I did: I used it for my own work before showing anyone, which kept me from adding features nobody asked for. And I put real effort into the client-facing side, because the person who signs never sees my dashboard, they see one page, and that page is the whole product.
What I skipped and now regret a little: I did almost no market research up front. I asked an AI what a solo dev could build, it suggested this space, the reasoning sounded good, and I just started. There were nights I wondered if I was building something nobody wanted. I still don't fully know. Today is the first real test.
It's a solo full stack build on Next.js and Postgres, nine languages, and I'm figuring out SEO from zero at the same time.
If you send proposals for a living, I'd genuinely like to know: what would it actually take to move you off PDFs? Honest teardowns welcome, that's more useful to me today than a nice word.
We're live on Product Hunt right now if you want to see it: https://www.producthunt.com/products/pactiamo
I think the biggest challenge is not replacing PDFs. It is fitting into the way people already work. Many freelancers already have their own proposal process and payment tools. If switching feels like extra work they will probably stay where they are. The all in one approach is interesting but I think the onboarding experience will decide whether people actually make the switch.
This feels familiar. Getting the signature can be frustrating, but in agency work the mess often starts earlier. You have to turn a fuzzy client conversation into clear scope, assumptions, options and a price everyone understands. That is usually where the back and forth begins.
I would consider leaving PDFs if I could show a clear baseline, add optional items and handle changes without rebuilding the whole proposal. Are you designing this mainly for solo freelancers doing fixed price work, or for agencies where several people may review the scope before the client sees it? Agencies probably need more structure, but the pain is definitely there.
Twenty years of running an MSP taught me the deal starts dying the moment you say "I'll send a proposal." What worked for us was building the proposal on the call: scope, price, and start date on one page before hanging up. Your one-link flow fits that motion, so I'd sell it as speed to signature, not proposal software.
Twenty years of that beats anything I've got, and "the deal starts dying the moment you say I'll send a proposal" is going to stick with me for a while. It also exposes a hole in how I've been measuring. My main number is time from sent to paid, which quietly assumes the clock starts when I hit send. You're saying it starts when they say sounds good on the call, and everything between that and me hitting send is decay I'm not even counting.
The uncomfortable part is that my product currently assumes you write the thing after the call. There's AI drafting to make that faster, but faster after the fact is still after the fact. Building it live while you're still on the phone is a different shape entirely. One page, scope price start date, sent before anyone hangs up. That's not a huge lift technically, it's more that I've been designing for the wrong moment.
Speed to signature is also sharper than anything on my page right now, and you're the second person this week to tell me I'm leading with features. I'm taking it. One thing I'd like to know since you actually ran this motion, did you build the page in front of the client on a screenshare, or just fill it in while talking and send the link before the call ended? I'd design those two pretty differently.
The real insight here is that you've identified friction as the actual cost in deal-making. Most teams optimize for getting to "yes" but they miss that every email back-and-forth, every tool-hop from proposal to signature to payment, is a chance for buyer's remorse to set in. Pactlamo removes that theater - one link, one interface, one journey. That's elegant.
The fact that you skipped market research upfront concerns me less than it would for other ideas because you were literally living this problem. Your own pain is usually a stronger signal than surveys. But the next test is critical: does the friction reduction actually move the conversion rate, or was the friction masking something else (like pricing, product-market fit, or wrong buyer persona)?
Thanks, though I don't want to take more credit than the friction fix actually earns. Removing friction only does anything for a deal that was already won. If a client is stalling because the price is wrong, or because I'm talking to someone who can't sign the check anyway, one link doesn't fix that and shouldn't pretend to. That's why I keep the scope this narrow. I'm not trying to convert people who never really said yes.
Which is why your test question is the right one, and my honest answer is I don't know yet. The way I plan to find out is to only look at deals that already got a verbal yes, and measure sent to paid. That number is either short or it isn't. If it stays long with the friction gone, then the friction was cover for something else and I'd rather find that out in two weeks than talk myself out of it for two months. There's a nice side effect too, taking the theater away makes the no arrive faster. Someone who won't sign a one click link isn't confused about the process, they're just not buying.
The buyer persona version is the one that actually worries me, because it's the slowest to show up. Somebody who sends two proposals a year feels none of this. Somebody who sends four a week feels all of it. So if the numbers don't move, my first suspicion won't be that the gap isn't real, it'll be that I built for the wrong frequency of user. Good problem to have compared to the alternative, since that one's fixable.
The "no idea if anyone opened it" part hits close to home. I run a marketplace where payment friction shows up differently — clients who pay by bank transfer have to wait for manual confirmation before their balance is usable, and that dead time between "money sent" and "money confirmed" kills momentum the same way an unopened proposal does. Ended up pushing people toward instant card payment for exactly that reason. Does Pactiamo handle payment methods with a confirmation lag (bank transfers etc.) any differently from instant ones, or is it card-only for now?
Right now it's actually the opposite of card-only. Everything runs on the confirmation-lag model, on purpose. Whatever method you use, a Stripe or PayPal link, your own payment link, a QR code, the client pays through it, marks "I've paid", and you confirm you got it from your dashboard. I don't hold the money and I don't auto-unlock on a webhook, so there's no instant-confirmed path yet and no per-method difference.
You're pointing at something real though. That dead time between "money sent" and "money confirmed" is a momentum killer, same as the unopened link. The one thing working in Pactiamo's favor is that the person confirming is the freelancer who actually wants the deal done, so the lag is usually just however long it takes them to glance at their account and hit confirm, not a bank's batch cycle. But it's still a manual step, and you've got me thinking about whether the client should at least see an expected "usually confirmed within X" so the wait doesn't feel like a void.
Down the road, wiring up a real instant gateway for the card-and-done crowd is on the list. For now the honest answer is every method is manual-confirm, and I'd rather be upfront about that than pretend there's an instant path that isn't built yet.
The “sounds good” → money gap is painfully real. Browser sign + pay in one link is the part freelancers actually feel.
Respect for dogfooding it on your own client work before launch — that’s usually what kills feature creep. On the research regret: what would “first real test” success look like for you in the next 2 weeks — signed deals through the product, or just reply volume here?
Signed deals, easily. Reply volume here is nice for my mood but it's a vanity number, none of these people have to actually trust the thing with a real client. The comments tell me the positioning resonates, they don't tell me it works.
So the two week bar is small and concrete: a handful of freelancers who aren't me send a real proposal through it and get paid, and I can look at the time between sent and paid and see it's short. Even three or four of those is more signal than a hundred upvotes. If nobody does that, the idea is validated in theory and dead in practice, and I'd rather know that in two weeks than pretend for two months.
Honestly your point about the research regret lands here too. I skipped the upfront research, so this launch is my research, and the only version of it that counts is money actually moving through the product.
Congrats on shipping. I think you've identified a real pain point it's rarely the proposal itself, it's everything that happens after the client says "yes."
The biggest selling point to me isn't the AI. It's having proposals, signatures, and payment all in one place without making the client create an account. That's the kind of friction that actually kills deals. One piece of feedback: I'd lead with the outcome instead of the features. Something like "Get from 'sounds good' to signed and paid in one link" is more compelling than listing AI drafting, legal checks, and reminders. Those are nice bonuses, but the faster payment is what grabs attention.
As for moving away from PDFs, I'd switch if the experience felt more professional than sending a PDF + invoice, not just more convenient. Clients need to trust the process immediately. Wishing you a successful Product Hunt launch. Hope you get plenty of honest feedbac it's the fastest way to find out what people actually value.
This is the most useful comment I've gotten, thank you. You're right that I've been leading with features. "Get from sounds good to signed and paid in one link" is better than anything I've written, I might just steal it outright.
The trust point is the one I'm going to sit with. I've been optimizing for convenient, and you're saying the real bar is professional, because a client's first reaction to a link they didn't expect is suspicion, not relief. Convenient helps the freelancer, professional is what makes the client comfortable clicking sign. Those aren't the same thing and I'd been treating them like they were.
That actually reframes a bunch of small decisions for me, like how the page looks the second it opens before anyone reads a word. Really appreciate you spelling this out, and thanks for the launch wishes.
Closing the gap between "sounds good" and an actual deposit is one of the biggest friction points in freelancing. Combining proposal, e-signature, and direct payment into a single seamless link completely removes the drop-off that happens when juggling PDFs and separate invoices. Brilliant execution!
Thanks, that's exactly the drop-off I was chasing. One honest clarification though, I don't actually hold the money. The link carries the proposal and the signature, then hands off to whatever payment method the freelancer already uses, and they mark it paid on their side. I stayed out of being a middleman on funds on purpose, partly so people aren't waiting on me to release anything, partly because I didn't want to become a payment processor overnight.
The part you nailed is the juggling. One link instead of a PDF plus a separate invoice plus a chase email is most of the win. Appreciate you taking a look.
I send proposals for a living. PDFs are a nightmare — especially when you're chasing down the signature while still trying to write copy for the next client.
The one thing that would move me off PDFs? Not the signing process. That part you solved. It's the follow-up. If your tool could also nudge the client automatically when they open the link and haven't signed yet — that would close the gap you're talking about.
The 'yes' to money gap is real. You're building in the right direction.
Good luck with the launch. I'll be watching
Yeah the follow-up is exactly the part I keep hearing, and honestly it's what I'm building next. Signing was the easy half. The awkward half is that a proposal goes out, the client opens it, gets pulled into something else, and it just sits there. Nobody wants to send the "hey did you see this" email for the fourth time.
So the plan is pretty much what you described. The tool already sees when a link gets opened and whether it's been signed. Turning that into a quiet automatic nudge when someone opens but doesn't sign is the obvious next step, and it closes the exact gap I was talking about instead of just tracking it.
You're the second person who sends proposals full time to point straight at this, so it's moving up the list fast. Appreciate you spelling it out. And thanks for watching, I'll try to make the follow-up worth the wait.
That gap is where so many freelance/sales deals quietly die — someone's genuinely interested, then momentum just evaporates before a contract or invoice ever gets sent. What's the biggest cause you've seen — is it more about slow follow-up, unclear next steps, or something else entirely?
From what I've seen so far it's mostly the boring one. Slow follow-up. The deal is basically won, both sides said yes, and then the proposal just sits in an inbox because everyone got busy. Nobody wants to be the person sending the fourth "just checking in" email, so it drifts.
The honest caveat is that not every stall is that. Some of them are stuck upstream, budget approval, someone internal has to sign off, the client wasn't actually ready. No tool fixes those, and I don't want to pretend it does. What I can tell apart is the two: a deal stuck upstream usually still gets opened and read, a buried one never even gets opened. That difference is what I'm leaning on.
So the short version, the biggest fixable cause is momentum leaking after a yes, not people saying no. Curious if that matches what you see on your end.
"Momentum leaking after a yes, not people saying no" is a really sharp way to frame it — it reframes the whole problem from a sales issue to more of a process/friction issue. The distinction between "stuck upstream but still opened" vs. "buried and never opened" is a great diagnostic too. On my end, I've seen the same pattern — the deals that die quietly are almost always the ones where nobody owned the follow-up, not the ones with a real objection behind them.
The product only works if it shortens already-won deals, not if it tries to rescue prospects who were never truly committed. I’d focus onboarding on freelancers with frequent proposals and track whether Pactiamo reduces days-to-payment, because that is the clearest proof the workflow solves a costly problem.
This is the clearest version of the thing I've been circling all thread. Already won deals, not rescuing prospects who were never in. Days to payment is the right metric too, better than the engagement numbers I was tracking, because it maps straight onto money the person actually feels. And the freelancer with frequent proposals is exactly who feels every day of that delay, so that is where onboarding should point. Saving this one, it basically wrote my next month for me.
That’s exactly the right metric to build around. If Pactiamo can consistently show that freelancers get paid several days faster, the value becomes concrete enough to justify the product without leaning on vague productivity claims.
The "sounds good" gap is one of the most expensive leaks in freelancing and nobody talks about it because it doesn't feel like a problem — it feels like the client being slow. But you're right, it's a process problem.
The fact that you dogfooded it before showing anyone is exactly the right call. Most proposal tools are built by people who've never spent an evening formatting a PDF that the client opens once and forgets.
One question: do you track where in the flow clients actually drop off? The sign → pay conversion might be less interesting than knowing whether they opened the link at all. A lot of "I'll review it this week" just means the email got buried — and that's a different fix than reducing signing friction.
You are pointing at the thing I care about most. Yes, I track opens and how far people scroll, and the single most useful signal so far is not the sign to pay step, it is whether the link got opened at all. Your read on "I'll review it this week" is right, most of the time it just means it got buried, which is why the automatic reminders matter more than I expected them to. Reducing signing friction only helps the deals that were already moving. Surfacing the ones that silently never got opened is a different and probably bigger fix, and I am honestly still learning which one moves the needle more. Good question to keep me honest.
The thing that jumps out is that you're solving a mechanics problem, not a psychology problem. Most "proposal delays" aren't about the PDF sitting in someone's inbox - they're about budget approval, internal sign-off, or the client not being actually ready.
But you're right that for the deals already won, the process is pure friction. The self-serve signing part is genuinely underrated. Clients signing in the browser and paying without account creation removes commitment friction that most B2B tools miss.
My question: how do you validate whether the delays you're solving are real blockers, vs. a symptom of deals that were stalled for reasons upstream? That's where I'd worry the product gets hit - you solve the flow, but the real deals still wait on budget cycles.
You have named it more precisely than I had. It is a mechanics problem, and I am not going to pretend the mechanics fix a deal that stalls on budget or internal sign off. Those were never mine to win. What I am going after is narrower, the deal that already had a yes in it and then leaked time and certainty on the way to money.
On how I validate it, honestly and imperfectly so far. The one thing I lean on is the open and attention data. A deal stalled upstream usually still gets the proposal opened and read, while the buried ones never get opened at all, and those two cases look completely different in the tracking. The complaint I heard most as a freelancer was never that my price was too high, it was that it got lost. That is the pile I am betting on. You are right that if that pile turns out to be small, the product gets hit, and that is the real risk I am watching.
One thing I'd flag from the payment side, since I built something similar (a one-time-purchase flow for a Mac app: Stripe checkout, webhook, then deliver a license, no server the customer ever sees).
The gap that bit me wasn't the workflow, it was trusting the wrong signal for "the client paid." checkout.session.completed fires when checkout finishes, not always when the money has actually settled. Delayed payment methods go through the same event before the charge clears, so if delivery is wired purely off that webhook you can end up granting access before you're actually paid, or double-processing if Stripe retries the webhook and the handler isn't idempotent.
Two things that saved me: checking payment_status explicitly instead of trusting the event type, and making the "unlock this" step idempotent (a unique constraint on the session or payment id) so a retried webhook, or the client refreshing the page after signing, doesn't fire twice.
Given Pactiamo also lives at the "did they actually pay" moment, this seems worth a deliberate look before it's the thing that quietly loses a deal you thought had closed.
This is the most useful comment on the thread, thanks for taking the time. You are describing the exact trap. I treat the paid event as a claim, not proof. The actual unlock keys off the provider's settled status plus a unique constraint on the payment id, so a retried webhook or the client refreshing the page after signing cannot double fire. The delayed method case you mention is the sneaky one, because in testing everything settles instantly and you never see it until a real bank transfer or some slow method walks through weeks later. It also helps that the provider is merchant of record here, so the settlement signal comes from them rather than me guessing from an event type. Keeping your payment_status point right at the front of my mind, that is the kind of bug that only shows up once real money is moving.
The gap between client approval and payment is a clear workflow problem.
What would convince you that the main reason deals stall is the proposal-to-payment process itself, rather than a broader issue around client trust, budget approval, or buying friction?
You'd be right to push back, and I'm not going to pretend the process is the main reason deals stall. Trust, budget, and internal approval kill far more deals than a clunky handoff, and most of those were dead before the proposal ever went out.
Where the process actually bites is narrower. It's the deals that already had a yes in them and then leaked time and certainty in the gap. The client was in, but the PDF sat unopened for a week, or the signature waited on a printer, or the invoice got buried under everything else. Honestly I can't measure that pile cleanly yet, which is the real answer to your question. The one signal I trust is that the complaint I heard most as a freelancer was never that my work cost too much, it was that it got lost in someone's inbox. That is the failure I'm building against, not the decision to buy. If that pile turns out to be small, that is a genuine risk to the whole idea.
Appreciate the honesty and context.
Would be good to continue the conversation as you learn more about that gap and how customers experience it.
What's the best email to reach you on?
Easiest is X, I'm @leomiller_dev and my DMs are open, that's usually the fastest way to reach me. If you'd rather do email, [email protected] works too. Either way I'll be digging into how real users hit that gap over the next while, so I should have more worth comparing soon.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.