Freelancers of IH — how do you actually deal with a client paying late (or never)?
UPDATE (AUG 02) : And here's what I'm building from the patterns: [ https://www.indiehackers.com/post/what-30-freelancers-taught-me-about-getting-paid-and-the-tool-im-building-from-it-4a3d878d8e ]
UPDATE (Jul 29): the compilation is now in the comments below ↓
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
Late-payment follow-up gets easier when you separate a reminder from a diagnosis.
A reminder assumes the only problem is forgetting. But an overdue invoice is usually sitting in a state:
The next message is different in each case. After the first polite nudge, I would usually ask what the invoice is waiting on and put an explicit next date on the thread instead of sending another generic "just checking in."
Third time you've handed this thread a structural upgrade. The reminder-vs-diagnosis split explains why generic bumps decay so fast — same message, five different underlying states. One refinement I'd test on your prescription: make the diagnostic multiple-choice. "Is this waiting on an approver, a PO, or a payment-run date?" turns a question the client has to compose an answer to into one they can answer in five seconds — and each answer tells you exactly which next message to send. Do you leave yours open-ended, or offer options?
For me the first reminder isn't really the hard part — it's that I usually don't know something's overdue until I go dig through a spreadsheet. I started keeping a hard line between "invoice sent" and "money actually in the account" so nothing slips by looking paid when it isn't. Built that as a small side project (getalisio.com, still very early, no real traction to brag about) mostly because I kept lying to myself about what was actually collected. Curious whether others here separate those two the same way, or if it's more of a gut-feel thing.
The stories back you up — and there's a name for what you're describing upthread: the invoice needs to be "a visible status with a next action," not a line in a spreadsheet you have to go interrogate. The cost of not separating those two showed up in the pile as well: one dev described the drag of not-quite-knowing — "part of my head was still stuck chasing the old money" — and slowing down on new work because of it. Most people run it on gut-feel until the gut gets burned; everyone who fixed it made the state explicit somewhere. A column, a board, a rule — the medium mattered less than the hard line.
And "looking paid when it isn't" is the sharpest phrasing of it I've seen — sent feels like progress, but only collected is real.
The "next action" part is what a spreadsheet can't hold. A status column tells you where the invoice is. It doesn't tell you this one has been sitting at "sent" for 34 days when your average is 11. Same data, completely different prompt to act.
That gap has a name — DSO, days from sent to paid — and measuring it is what turns "they're slow" from a feeling into something you can quote back to them. "Your last three invoices averaged 41 days" is a very different conversation than "you guys always pay late."
The trap I keep running into building this: with four invoices, an average is noise. The honest move is to show the number only when there's enough behind it, and say so out loud when there isn't, instead of printing something confident that nobody should trust.
And yeah — "part of my head was still stuck chasing the old money" is the real cost. It's not the money. It's the tab left open.
"34 days when your average is 11" — that's the difference between a status and a prompt. And quoting DSO back ("your last three averaged 41 days") does double duty: it depersonalizes the escalation for the client, but before that it answers the sender's own question — am I being unreasonable? The number grants permission to be firm. Your honest-data rule is going in my notes verbatim too: show the metric only when there's enough behind it, and say so when there isn't. "The tab left open" is the best one-line description of the real cost I've collected. Thank you for both rounds.
The compilation, as promised — what 30+ freelancer stories (and this thread) say about getting paid.
Method note first: this is patterns, not statistics — drawn from public posts across freelancer communities plus the answers in this thread. Where something was actually practiced by the person telling it, I say so; where it's still a hypothesis, I mark it.
1 · Why the first reminder gets delayed (it's almost never forgetting)
Five mechanisms kept showing up:
The buried email. Most "late" is a client who forgot or an inbox that ate it — not a "no."
The avoidance spiral. One founder-freelancer described rewriting the same reminder four times over two weeks and never sending it. No cost-benefit running — just dread on a loop.
The creditor switch (AleksandraZhd's framing, which two practitioners here independently endorsed): up to that moment you're a collaborator; the reminder makes you a creditor, and people dread that switch more than the lost days.
Admin friction on the client side — missing PO, wrong billing contact, approver on vacation, payment-run timing (artemissystems' bucket). Looks like ghosting, is actually paperwork.
Clients learn (SongTrailer): once work continues past a due date, the client learns the deadline has no consequence. Every unenforced deadline is a training signal.
And the reason one email feels so heavy: it's doing three jobs at once — did you forget? are we still good? am I now the person who has to chase you? (artemissystems). It's not a payment request; it's a relationship renegotiation.
2 · The one law everyone converged on
Five people, five phrasings, one rule: a system, not a decision · policy, not personal · structure, not threats · process, not a courage problem · process, not punishment.
Everything about enforcement gets established before enforcement. The late fee announced at signing (that then never needs charging). The pause rule stated up front. The billing voice introduced on day one, not at escalation. When the consequence was declared early, enforcing it reads as process. Introduced late, it reads as punishment — or a costume.
3 · What practitioners here actually did (tested, first-person)
Move the first touch to before the due date (Kan). A pre-due note — "quick heads-up, invoice X is due Friday; anything you need from my side, a PO number or a re-send?" — catches the admin class of lateness without implying distrust (artemissystems' wording). Bonus: when day 7 comes, your message is a reply in an existing thread, not a first awkward contact.
Day-after-due first reminder (SongTrailer): "waiting longer has never improved the relationship or increased the chance of getting paid." His economics: leverage is strongest before more work ships — pause early while the amount is small, or negotiate late when it's large.
A fixed ladder (OrionOperator, day 1 / 7 / 14): friendly heads-up with the link → firmer with a specific date → contract reference with the late fee. His headline result: "I almost never had to actually charge the fee — its existence alone made clients act faster." The fee is a deterrent, not revenue.
Leverage as structure, not threats: a 30–50% deposit that quietly filters the clients who were never going to pay ("the ones who push back hardest on the deposit go quiet at the end" — Kan); work living on staging until the final invoice clears (Kan); a stop-work clause that triggers without a hard conversation (GregoryScottHenson); and for clients too big for deposits — net-15 against a signed PO, so there's a paper trail to escalate on.
When fully ghosted — a status reset, not a threat (artemissystems): "I'm going to mark this as unresolved on my end unless I hear otherwise by [date] — if it's an admin issue, send me the right next step." Then stop improvising: pause work/access, resend with original terms, collect the paper trail, one final notice with a date, and decide in advance whether the amount is worth small claims or writing off. His line is the whole thread in one sentence: the invoice stops being an awkward relationship problem and becomes a visible status with a next action.
4 · The open design question: whose voice is the reminder in?
The most interesting unresolved thread: if the creditor switch is the real cost, does the reminder work better when it visibly comes from "the system" instead of you? The rule that emerged (AleksandraZhd): don't introduce a system voice at escalation — establish it at signature, or don't use one. Mid-sequence, it reads as a mask. Below a certain engagement size there is no plausible "billing department," and honesty beats theatre — though naming your own process out loud ("this moves into my overdue-payment process") seems to thread the needle at solo scale.
5 · Marked as hypothesis (repeated often, not yet proven)
Amount + payment link in the first three lines. One specific confirm-by date per email. Anchoring the framing in the deliverable, not the invoice. Timing/consistency mattering more than wording. And raim_osm's falsifiable bet: the worst late-payments cluster almost entirely in no-deposit, net-30 jobs.
Thanks to everyone who answered — Kan, SongTrailer, OrionOperator, GregoryScottHenson, artemissystems, AleksandraZhd, raim_osm, Yuki_Code1, and several people elsewhere whose stories are anonymized above. I'm still collecting: if a client went quiet on you recently, I'd still love to hear what happened and what you sent.
One useful "completely ghosted" version I would use after the normal reminder sequence has failed:
The main thing I would avoid is jumping straight from friendly reminder to legal-sounding threat. I would make the next message a status reset:
"Hey [Name], I have not heard back on invoice #[X], now [N] days overdue.
I am going to mark this as unresolved on my end unless I hear otherwise by [date]. If there is an admin issue, wrong billing contact, missing PO, or payment-run timing problem, send me the right next step and I will update the record.
If I do not hear back, I will pause any remaining work/access and move this into my overdue-payment process."
Then I would stop improvising and follow the process you already decided:
The useful part is not that the wording is magic. It is that the invoice stops being an awkward relationship problem and becomes a visible status with a next action.
This fills the gap the thread had — the missing stage between "friendly" and "legal-sounding." And the status-reset framing is exactly right: stop asking, start recording. "Mark this as unresolved on my end" does something subtle — it moves the sender from request-mode into ledger-mode without any corporate costume. That might be the honest version of "the system chases" at solo scale: not a billing persona, just my process, named out loud.
Your closing line is the whole thesis of this thread in one sentence — the invoice stops being an awkward relationship problem and becomes a visible status with a next action. Going in close to verbatim. Between this and the ladders above, the write-up now covers the full arc, pre-due to endgame. Thank you.
On the question you're most curious about — why the first reminder gets delayed: it's almost never that people forget. It's the creditor reframe. Sending reminder 1 feels like changing the relationship from peer to collector, so we stall.
The cleanest fix I've seen isn't better wording, it's taking yourself out of the send. If reminder 1 fires automatically on day 1 overdue — same friendly "heads up, this slipped" tone — the awkward decision never lands on you personally. It's just "the system." Freelancers who automate that one message get paid faster and never feel the friction.
Structurally, two things beat any script: net-7 instead of net-30 (shrinks the window the money can drift), and a deposit / card-on-file up front. My bet on your data: the worst late-payments will cluster almost entirely in the no-deposit, net-30 jobs. That's the pattern worth surfacing.
The no-deposit + net-30 clustering is a sharp, falsifiable prediction — logged exactly as stated; if these stories ever get quantified, that's the first cut to run. And you're the third person converging on the same fix from a different angle: take the human out of the first send specifically. Automate reminder one, keep judgment for escalations — that might be the clearest design insight in this thread.
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.
Yes — please drop the ghosted-escalation script; the compilation lands here on the 29th and it would fit right in. This comment is going in nearly whole: the day-1/7/14 ladder, and especially "I almost never had to actually charge the fee — its existence alone made clients act faster." Three people have circled the deterrent-not-revenue idea, but you said it cleanest.
One question for the write-up: what did collections look like for you before net-7 and the fee clause — the worst one that made you build this system?
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.
"Waiting longer has never improved the relationship" — that line settles a debate running through this whole thread, and it's going in the compilation. One follow-up: when you've paused work after a second missed deadline, did it ever cost you the client — or did it mostly snap things back on track?
In my experience, pausing the work usually resets the relationship rather than ending it. The serious clients pay once the consequence becomes real; the unreliable ones may disappear, but that is often better than continuing to work unpaid.
The key is to make the rule clear before the invoice is overdue, so it feels like a process rather than a punishment.
"Resets the relationship rather than ending it" — that's the answer to the fear running under this entire thread. And "process rather than punishment, made clear before it's overdue" lands on the same law three others reached from different angles: everything about enforcement gets established before enforcement — the late fee that never needs charging, the billing voice introduced at signature, the pause rule stated up front. You've each described the same rule.
Last one from me: was there a specific client or invoice that taught you this — the one that made you adopt the day-after rule in the first place?
It wasn’t one dramatic invoice so much as a repeated pattern: once work continued after the due date, the client learned that the deadline had no real consequence.
The day-after rule came from realizing that leverage is strongest before more work is delivered, not after the balance has grown. Pausing immediately keeps the amount small, the boundary clear, and the conversation professional. Since adopting it, payment issues have become much easier to resolve.
"The client learned that the deadline had no real consequence" — that's the sharpest mechanism in the whole pile: late payment as trained behavior, taught one un-enforced deadline at a time. And "leverage is strongest before more work is delivered" gives the day-after rule its economics — pause early while the amount is small, or negotiate late when it's large. Both are anchoring the write-up.
Thank you for going three rounds on this. The compilation lands in this thread on the 29th — your answers run right through the middle of it.
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."
Coming back to this because two practitioners have since landed on your exact frame — one wrote "AleksandraZhd nailed it: it's the creditor reframe." Consider it the thread's consensus diagnosis at this point.
The design nuance I'd add from the stories: the switch cost isn't constant across the sequence. A pre-due, deliverable-anchored note is still collaborator-talk — no switch happens. The cost peaks at the firm/final stages, which suggests the voice could travel: yours early, "your billing system's" later — visibly scheduled, replies still landing with you. The freelancer never personally becomes the creditor; the system does, exactly when it matters.
One thing I'd love your read on: have you seen the visible-system voice actually tested — or backfire? Some clients might read "they set a robot on me" into it, especially in small, personal engagements.
I haven't A/B'd it for late payments specifically, so take this as a mechanism guess, not tested data. From building billing notifications though, what decides backfire-versus-works isn't the client's size, it's whether the system voice was visible from day one.
If the whole engagement is personal emails and then "your billing system" appears at the firm stage, it reads as exactly what your client fears: a mask you chose to hide behind, since everyone knows it's still you. Introduce the same billing identity at contract signing — first invoice, receipts, the gentle pre-due nudge all from "billing" — and the final firm note is just that voice you've both been hearing all along, getting firmer. Continuous, not a sudden costume.
So the rule I'd test: don't introduce the system at escalation, establish it at signature. The freelancer stays the collaborator the whole time because they were never the billing voice to begin with.
And your small-engagement instinct is right. Below some size there's no plausible system, and faking one is worse than a warm, direct personal reminder. The visible-system move needs a real system to be credible, and when there isn't one, honesty beats theatre.
That reframes it cleanly — the failure mode isn't "system voice," it's the mid-sequence costume change. Establish at signature, never at escalation. And your small-engagement caveat cuts the other way too: below a certain size the warm personal note isn't the fallback, it's the correct tool. "Honesty beats theatre" is going in verbatim.
So the testable rule this thread produced: voice is an engagement-level choice made on day one — personal throughout, or billing-identity throughout — never a step-level switch. Sharper than what I walked in with; thank you. This exchange anchors the "whose voice is the reminder in" section of tomorrow's write-up.
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.
This is exactly the shape I was hoping the research would surface — thank you. "The cost was the drag, not the amount" is the best articulation yet of why this problem hides: never one big hit, just part of your head permanently renting space to old invoices. That line is anchoring the compilation (anonymized or credited — your call).
And the retainer answer maps the frontier: pre-billing and prepaid blocks so "the work just pauses instead of me sending a reminder" — structure doing the chasing. The net-15-against-a-signed-PO trade for big clients is a pattern I haven't seen written down anywhere. Going in too.
Last one, promise: back before you restructured — if that day-one nudge had gone out automatically from "your billing system" (visibly scheduled, replies still landing with you), would you have let it run? Or did it feel like it had to come from you back then?
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.