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