Freelancers of IH — how do you actually deal with a client paying late (or never)?
I'm researching this space (and exploring building in it). If you've freelanced: what did your worst late-payment look like — amount, how late? What did you actually send or do, and did it work? And the question I'm most curious about: how long did you put off sending that first reminder, and why? I'll compile the patterns (the wording and timing that actually got people paid) and post them back here next week.
Trending on Indie Hackers
The wording question is the most useful one here — so let me actually answer it with concrete scripts:
Reminder 1 (day 1 overdue): Zero pressure, assume oversight. "Hey [Name], quick heads-up — invoice #[X] for $[Y] was due [date]. Flagging in case it slipped through! [payment link]" No apology, no accusation. Tone: colleague, not creditor.
Reminder 2 (day 7): Slightly firmer, but still collaborative. "Following up on invoice #[X], now 7 days past due. Let me know if there's anything on your end I should know about — otherwise could you arrange payment by [date] to keep things on track?"
Reminder 3 (day 14): Reference the contract explicitly. "Per our agreement, invoice #[X] is now 14 days overdue. A 2% late fee now applies per month. Please arrange by [date] or reach out today so we can resolve this."
The single biggest improvement I made: switching to net-7 terms and adding a late fee clause. I almost never had to actually charge the fee — its existence alone made clients act faster on reminders 1 and 2.
On why people delay sending reminder 1: AleksandraZhd nailed it. It's the creditor reframe. The fix is to make it a scheduled system task, not a human choice. When the calendar event fires, you're just executing a workflow — and the social cost disappears.
Happy to drop the "completely ghosted" escalation script here too if useful for your research.
I send the first reminder the day after the invoice is due; waiting longer has never improved the relationship or increased the chance of getting paid. After a second missed deadline, I pause the work and make it clear that delivery resumes only once the outstanding balance is settled.
The cleanest solution I've found: front-load the risk transfer. Require 50% upfront before starting work, 50% on delivery. This shifts the incentive - they're already invested, so they're more likely to follow through. Late payment becomes their problem since they've already paid half.
If they push back on 50/50, that's a signal - either they're cash-constrained (risky) or they're the type of client that doesn't take freelancers seriously. Both are red flags worth heeding.
For longer contracts (weeks of work), break it into milestones: 30% upfront, 35% mid-project, 35% final delivery. Same principle - their money is on the table incrementally.
Also: short payment terms in the contract (net 7, not net 30). Every day that passes after delivery is another day they're holding your money. And if they miss net 7, automated late fees kick in - I use 1.5% per month, which compounds quickly and incentivizes payment.
The "never" scenario is usually better caught before you start than dealt with after. Quick phone call to vet: their communication style, how they handle your questions, whether they're vague about budget/timeline. Bad signal = pass.
On the question you're most curious about, the delay before the first reminder: people put it off because sending it reframes the relationship. Up to that point you're a collaborator. The reminder makes you a creditor, and freelancers dread that switch more than they mind the lost days.
That's the real reason the process advice above works. It isn't discipline, it's that payment-method-on-file and scheduled auto-billing take the human out of the awkward loop. The system chases, not you, so the first nudge costs nothing socially and goes out on day one instead of week three. If you're building here, that's the emotional job to design around: not "how do I write a firmer reminder" but "how do I make the reminder not feel like it came from me."
This is an interesting topic. I'm curious to see the patterns in the responses because payment delays seem to be one of the biggest challenges for freelancers. It would also be useful to know whether upfront deposits or milestone-based payments significantly reduce the chances of late payments.
Early signal from this very thread says yes — with a twist: deposits work partly as a filter, not just protection. Two veterans above noted the clients who push back hardest on a deposit are usually the same ones who go quiet at the end. And even then, deposits and milestones leave the back half of the invoice exposed — which is where most of the collected stories actually live.
Twenty years of B2B services taught me collections is a process problem, not a courage problem. What fixed it for us: payment method on file before work starts, automatic billing on a schedule the client agreed to in the contract, and a stop-work clause that triggers without a hard conversation. The freelancers who wait weeks to send the first reminder are usually the ones who never said the payment terms out loud at the start.
Twenty years compressed into "a process problem, not a courage problem" — that's going into the compilation as-is (anonymized). Your last line especially: the freelancers who sit on the first reminder are usually the ones who never said the terms out loud at the start. It reframes the whole thing — day-30 dread is really a day-0 omission.
One question from the freelancer side of the fence: payment-method-on-file and auto-billing assume the client accepts that structure. For solos billing clients bigger than them — where's the floor? A stop-work clause in the contract? Stated terms plus a pre-due heads-up? Curious what the minimum viable version of your system looks like.
The bucket that stands out to me is admin delay, because it rarely looks like forgetting. It looks like a founder who is already juggling five other things, and the invoice reminder is the one task that never got written down anywhere, so it waits until something else forces it to the surface. I built FounderFlow because I kept seeing that same pattern, not just with invoices but with anything that only lives in someone's head. Curious whether the founders you talk to can name which bucket they fall into before you ask, or if they only figure it out once you frame it that way.
Good question — from the stories so far: almost never before, only in the telling. People describe behavior ("I rewrote it four times," "I kept waiting because they've been good for years") and the bucket emerges from that. Nobody arrives saying "I'm an avoidance-spiral case." Probably matters for anyone building here: the diagnosis has to come from observed behavior, not a self-report form.
Following this thread — curious what's worked for people. In my experience, milestone-based payments upfront cut down on this a lot, but I'd love to hear how others handle it once a client's already gone quiet.
The post-quiet stage is where most of the collected stories live. The pattern that keeps repeating: (1) a short zero-guilt bump — "floating this back up in case it got buried" — because most silence is a buried email or an avoidance spiral, not a decision; (2) amount + payment link in the first three lines, one specific date to confirm by; (3) if there's real leverage, state it as structure, not threat — one freelancer recovered by pointing out they still owned the rights until payment, and a dev in this thread keeps work on staging until the final invoice clears. Milestones upfront + that ladder for the quiet ones covers most of the map.
When it happened to you — a client going quiet even after milestones — what did you end up sending, and did it work?
This is genuinely one of the most useful breakdowns I've seen on this — especially the "state it as structure, not threat" point. To answer your question: I haven't had a client go fully quiet after milestones yet, but I've started front-loading smaller milestones specifically to avoid ever hitting that stage. Curious if you've seen it work better when the first message references a specific deliverable vs. just the invoice itself?
Honest answer: no clean A/B in the pile yet — but the wins people described skew deliverable-anchored. The freelancer who recovered via rights framed it around the work ("I still own the deliverables until…"), and the pre-due note that catches admin blockers works largely because it reads as project communication, not money-talk. The three-signals point upthread explains why: an invoice-only message is pure payment talk; referencing the specific deliverable turns it back into a status update about work you both care about.
The synthesis I'd defend: anchor the framing in the deliverable, keep the mechanics — amount, link, one specific date — in the first three lines. The deliverable is the why, the invoice is the how.
And front-loading smaller milestones is a smart move — you're engineering the quiet stage out of existence. If a client ever slips through anyway, I'd love the postmortem. Full patterns land here on the 29th.
"The deliverable is the why, the invoice is the how" is a great one-liner — I'll probably borrow that framing next time I need to write one of these messages myself. And noted on the 29th, I'll keep an eye out for the full pattern write-up. Appreciate you taking this as seriously as you have across the thread.
The thing that changed this for me was moving leverage earlier, before the work is done. A deposit up front, usually 30 to 50 percent, quietly filters the clients who were never going to pay the last invoice anyway. The ones who push back hardest on the deposit are almost always the same ones who go quiet at the end.
Since I come from the dev side, the other piece is that the work lives on my infrastructure until the final invoice clears. Staging, not production. It is not a threat you announce, just how the engagement is structured, and it removes the chasing because nothing ships until payment does.
On your actual question about the first reminder: early on I would sit on it for a week or more, and the reason was exactly the signal problem someone already pointed out here, the reminder felt like it was accusing them. Pushing the first touch to before the due date is what fixed it for me, so by the time anything is late the follow-up is just a status check and not the first awkward contact.
This is the first comment from someone who's actually been through the tunnel — thank you. Two things are going straight into the compilation (anonymized): the deposit-pushback predictor — "the ones who push back hardest on the deposit go quiet at the end" is a screening signal I haven't seen articulated anywhere — and "not a threat you announce, just how the engagement is structured." Structure, not threats.
Your fix also matches the strongest pattern in the pile: moving the first touch to before the due date, so the late follow-up is a status check in an existing thread instead of a first awkward contact. You lived the signal problem and engineered around it.
Two questions, if you're up for them: (1) before you restructured — roughly how much was typically stuck, and for how long? (2) what still slips through even now — clients too big to accept a 30–50% deposit, or work that staging can't protect (retainers, consulting hours)?
On (1), it was never one big hit, which is what made it easy to ignore. Usually one or two invoices at a time, a few thousand each, dragging 60 to 90 days past due. The cost was the drag, not the amount. I would slow down on new work because part of my head was still stuck chasing the old money.
On (2), you found the real gap. The deposit is clean for project work because there is a clear deliverable to gate. Retainers and hourly are exactly where it leaks, since there is no single ship moment. What worked for me was billing those before the period, not after. Monthly retainer paid before the month starts, hours drawn down from a prepaid block, so the work just pauses when the balance hits zero instead of me sending a reminder. For clients too big to do a deposit, I trade it for net-15 against a signed PO, so at least there is a paper trail I can actually escalate on.
I don't have a useful personal war story here, but one pattern I would separate in the research is whether the first reminder is being asked to do too many jobs.
A reminder after the due date often carries at least three signals at once:
That is why people delay it even when the amount matters. They are not only asking for payment; they are renegotiating the relationship.
The prevention angle is interesting because a pre-due note can be much less loaded. Something like: "Just a quick heads-up that invoice X is due Friday. Do you have everything you need on your side, or is there anything I should resend before then?"
That catches admin blockers without implying distrust. Then if it becomes late, the next message is not the first awkward contact; it is a status follow-up.
So I would probably track three buckets separately:
Those probably need different products. Recovery tools help the first and third. Prevention tools might be stronger for the first two.
This might be the most useful comment on the thread. The "three jobs in one email" framing explains the dread better than anything I've collected — it's not a payment request, it's a relationship renegotiation. And your pre-due wording is genuinely better than what I had: "anything I should resend before then?" catches the missing-PO/approver class of lateness without implying distrust. Underrated side effect: once that pre-due note exists, the day-7 message is a reply in an existing thread, not a cold open — the awkwardness never gets to reset.
One gentle pushback: I'm not sure prevention and recovery are different products so much as different steps of one sequence — a pre-due admin-catcher, then escalating follow-ups if it slips. Same system, same voice, no seam. Your buckets would then drive the wording per step rather than the tool choice. One addition from the stories: client-side "admin delay" also includes payment-tech failures (expired card, blocked transfer) — those need a "let's fix the rail" email, not an intent-probing one. Your taxonomy is going straight into the compilation — thank you.
That distinction feels right. If the diagnosis has to come from observed behavior, the product needs to notice the pattern quietly in the background rather than asking the freelancer to label their own client relationships after the fact. I would be curious whether the timing of the first reminder ends up being a stronger predictor than the wording people eventually use. Looking forward to the compiled patterns next week.
I'm curious what convinced you the biggest opportunity is helping freelancers recover overdue payments rather than helping them avoid getting into that situation in the first place.
Did your research point more strongly toward recovery than prevention?
Honest answer: nothing has convinced me yet — that's what this thread is for. Early pattern says the prevention/recovery line is blurrier than it looks: the same pre-due heads-up that prevents admin-related lateness becomes step one of recovery if things slip anyway. Holding conclusions loosely until there are more first-person stories in the pile. If you've freelanced (or hired freelancers), your worst late-payment story would help me more than my thesis 🙂
Appreciate the context.
Would be interesting to continue the conversation as you collect those stories.
What's the best email to reach you on?
The best place is honestly right here — everything I collect gets compiled and posted back into this thread on the 29th, so following the thread is the conversation. And if a story of your own comes to mind before then (from freelancing or from the hiring side), drop it here so others can build on it too. 🙂
Makes sense, Han.
I'll follow along with the discussion here. The pattern that emerges from those stories should be interesting to see.
The delay in sending that first reminder often reveals something deeper - you're calculating whether the client relationship is worth the awkwardness vs. the actual revenue impact. Early reminders signal you value the small payment relative to the relationship; long delays signal you've written it off mentally. The pattern might not just be about payment recovery but about how freelancers assess sunk vs. future cost of managing that client.
This is a sharp frame — and it matches about half of what I'm collecting. The relationship-calculus version definitely shows up: one freelancer described waiting 6+ months on a $300 invoice from a long-term client, fully aware she's trading the money for the relationship. But the other half doesn't look like calculation at all — it looks like avoidance: someone described rewriting the same reminder four times over two weeks without ever sending it. No cost-benefit running. Just dread on a loop.
So maybe the delay has two species: a deliberate write-off (your model) and a paralysis spiral (no model at all). One design consequence I find interesting: a heads-up sent before the due date carries zero relationship signal — the calculus never gets to start.
Did you freelance yourself? Curious whether you've ever caught that calculation running live — and what tipped it either way.