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
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.
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.