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