This episode gets into the operational side of freelancing that most people skip. The core argument is that a single freelance client isn’t diversification — it’s a job without benefits, with all the risk of a full-time position and none of the protections. The recommended minimum client load is three, with no single client representing more than fifty percent of income. Four to five clients is better for stability and leverage.
On the contract side, the episode covers three critical elements: revision windows (a limited number of rounds within a defined time period), explicit scope-of-work language that specifies what’s included and excluded, and a change order process that makes scope creep billable without friction. Payment terms are also covered: always take a deposit up front (fifty percent for new clients), use milestone payments for larger projects, and negotiate kill fees to protect against last-minute cancellations.
#2649: Freelancing Without Getting Burned: Clients, Contracts & Cash Flow
How many clients do you need to survive? And what contract clauses actually protect you?
Episode Details
- Episode ID
- MWP-2808
- Published
- Duration
- 33:25
- Audio
- Direct link
- Pipeline
- V5
- TTS Engine
-
chatterbox-regular - Script Writing Agent
- deepseek-v4-pro
AI-Generated Content: This podcast is created using AI personas. Please verify any important information independently.
Downloads
Transcript (TXT)
Plain text transcript file
Transcript (PDF)
Formatted PDF with styling
Never miss an episode
New episodes drop daily — subscribe on your favorite platform
New to the show? Start here#2649: Freelancing Without Getting Burned: Clients, Contracts & Cash Flow
Daniel sent us this one — and I want to frame it properly because it's actually several questions wrapped in one. He's been contracting and self-employed for years, and he wants to talk about the stuff that determines whether you succeed or fail that has nothing to do with being good at what you do. Specifically, he's asking about a minimal viable client load, why having a single client is always a bad idea, and the nuts and bolts of contracts and billing — how to set terms, avoid scope creep, handle deposits, net thirty billing, all the practical mechanics that keep you from getting burned. And Herman, before we dive in — DeepSeek V four Pro is writing our script today.
Fresh ink from DeepSeek. I like it. So this topic — Corn, this is the stuff nobody talks about when they romanticize freelancing. They talk about freedom and working in pajamas. They don't talk about the client who comes back three months later with a fourth round of revisions while you're on holiday.
And Daniel's point about risk is the one I wish more people understood. The conventional wisdom says a full-time job is the safe route and self-employment is the risky one. But if you're in an at-will employment jurisdiction, your entire income can vanish on a Tuesday afternoon because someone in a conference room decided to restructure. That's a single point of failure.
That's exactly the framing. And I think the first thing to say is that a single freelance client isn't diversification — it's a job without benefits. You've traded your W-two for a ten-ninety-nine, you've lost your health insurance, your paid leave, your employment protections, and in exchange you've gotten... The illusion of independence?
Daniel's right that clients will actively push you toward this arrangement. They'll offer attractive terms, they'll dangle a retainer that looks like a salary, they'll say they want you to be "part of the team." It sounds great until you realize you're in a pseudo-employment relationship where they have all the control and you have none of the protections.
I saw a breakdown of this on the Freelancers Union site a while back — they call it "misclassification risk" from the client's side, but from the freelancer's side it's worse. You're dependent on one source of income, you've stopped marketing yourself, your network atrophies, and if that client goes away you're starting from zero. It can take months to rebuild a pipeline.
Let's talk numbers. Daniel asked for a minimal viable client load. What's your number?
I'd say three is the floor. Three clients where no single one represents more than fifty percent of your income. That's the number where if you lose one — and you will lose one eventually, projects end, budgets get cut, companies get acquired — you're hurt but you're not in freefall.
I'd go further and say three is the absolute minimum, but four to five is where you actually sleep at night. And I know people will push back and say that's too many to manage, that you can't do quality work across that many relationships. But that's a time management problem, not a structural one.
And it depends on what kind of work you're doing. If you're doing high-touch consulting where each client needs fifteen or twenty hours a week, okay, three might be your ceiling. If you're doing project-based work with bursts of intensity, you can handle more. But the principle holds: no single client should be able to destroy you.
The other thing about the single-client trap — and Daniel hinted at this — is that it warps the relationship. When you have one client, you can't say no. You can't push back on scope creep. You can't enforce boundaries. Because what are you going to do, fire your only client? So you end up saying yes to everything, working nights and weekends, and building resentment.
The client doesn't even respect you more for it. They just learn that you're available at eleven PM on a Saturday. I've seen this pattern so many times. The freelancer thinks they're building goodwill by being endlessly accommodating, and the client just recalibrates their expectations downward — or upward, from the freelancer's perspective — about what's reasonable to ask.
That's the client load question. Three minimum, four to five ideally, no single client above fifty percent. Now let's get into the contract stuff, because this is where Daniel's experience really shows. The revision problem he described — the client who comes back months later after something was supposedly approved — that's a classic failure of contract language.
It's one of those things where you don't know you need it until you've been burned. Daniel mentioned he ended up being "that guy" who says you get precisely two revisions and anything extra is billed separately. And he said he became that guy reluctantly, but he became that guy because of that one client in five who abuses the system.
Every freelancer I know has a version of this story. The contract that didn't specify a revision window. The project that was "approved" verbally but never signed off in writing. The client who interprets "unlimited revisions" to mean "I can iterate forever at no additional cost.
Let's break down what a solid contract actually needs. First, scope of work. And this is where most people are too vague. They write something like "design website" or "write white paper." That's not a scope. That's a topic sentence.
A real scope of work specifies deliverables, formats, lengths, number of pages, number of screens, number of words. It specifies what's included and — this is the part people skip — what's explicitly excluded. If you're writing a white paper, how many words? How many interviews? How many rounds of research? Are graphics included? Is sourcing included? What's the citation format?
Daniel's example is perfect. You need three things: a number of included revision rounds, a definition of what constitutes a revision versus a new request, and a time window. So something like: "Two rounds of revisions are included. Revision requests must be submitted within fourteen days of receiving the deliverable. Requests submitted after fourteen days will be treated as new work and billed at the standard rate.
The time window is the part people forget. Without it, you get the client who sits on a draft for three months and then comes back with changes, and you're expected to drop everything because technically you haven't done your second round of revisions yet.
It's not just about fairness to you — although that matters. It's also about project momentum. If a client takes three months to get back to you with feedback, the context has evaporated. You've forgotten the nuances of the project. You've moved on to other work. Restarting is cognitively expensive.
Daniel mentioned the asymmetry problem, and this is real. When you're a solo freelancer and the client is Microsoft or some large organization, they're going to insist on using their contract template. You're not going to win that fight. But that doesn't mean you're powerless. You can still negotiate specific clauses within their template.
In my experience, large organizations are actually easier in some ways. Their legal departments have standard fallback positions. They have processes. The real danger is the mid-size company that doesn't have a formal procurement process but still has enough leverage to push you around. They'll send you a contract that some founder drafted in a Word document five years ago, and it's full of landmines.
Let's talk about payment terms, because this is where a lot of freelancers leave money on the table — sometimes literally. Daniel asked about net thirty billing, deposits, all of that.
Net thirty is standard but it's terrible. You're essentially extending thirty days of credit to a client. If you invoice on the first of the month and they pay net thirty, you're waiting until the end of the month — and that's if they pay on time, which many don't. Net sixty is worse. Net ninety is basically you being a bank.
Large companies are notorious for this. They'll have a policy of net sixty or net ninety, and they'll still manage to pay late. I've heard stories of freelancers waiting a hundred twenty days for payment from Fortune 500 companies. The freelancer is supposed to be grateful for the "prestige" of the client while their rent is due.
What do you do? Always, always, always take a deposit up front. For new clients, fifty percent is standard. For established clients with good payment history, you might go down to twenty-five percent. But never start work without money in hand. It's the single best filter for serious clients versus tire-kickers.
It aligns incentives. If the client has paid fifty percent up front, they're motivated to give you timely feedback and keep the project moving. If they've paid nothing, they can ghost you for six weeks and it costs them nothing.
Second, milestone payments. For larger projects, break the work into phases and tie payments to deliverables. Phase one deliverable, phase one payment. Phase two deliverable, phase two payment. This limits your exposure — you're never owed more than one phase's worth of work.
Third, kill fees. This is the clause that says if the client cancels the project, they pay a percentage of the remaining contract value. Because here's what happens without a kill fee: you turn down other work to reserve capacity for a client, the client cancels the project in month two of a six-month engagement, and you're left with nothing and a hole in your calendar.
Kill fees are hard to negotiate, I'll be honest. Clients resist them because they feel like they're paying for nothing. But the way to frame it is: you're paying for the opportunity cost. I reserved time for you that I could have sold to someone else. If you cancel, I need to be made whole for that lost opportunity.
You don't have to be aggressive about it. A sliding scale works well — cancellation within the first thirty days is twenty-five percent, within sixty days is fifty percent, after ninety days is seventy-five percent. Something like that. The exact numbers depend on the project.
Let's talk about the scope creep problem specifically, because this is where contracts meet reality. Scope creep isn't usually malicious. It's death by a thousand small requests. "Can you just add this one thing?" "Could we tweak that?" "Oh, while you're in there...
The freelancer says yes because saying no feels unprofessional. You want to be helpful. You want to be easy to work with. And then you look up and you've done an extra forty hours of work for free.
The solution is a change order process. It doesn't have to be formal or intimidating. It can be as simple as an email that says: "That sounds like a great addition. It's outside the original scope, so I'll put together a quick estimate for the additional work." You're not saying no. You're saying yes, and here's what it costs.
The key is to make the change order process routine and low-friction. If every scope change requires a formal document and a meeting, you'll avoid doing it because it's too much overhead. But if it's just an email confirmation and an updated estimate, you'll actually use it.
This protects the client too, by the way. A good change order process means the client knows exactly what they're getting and what it costs. There's no surprise invoice at the end. The alternative — just doing the extra work and billing for it without prior agreement — is how you get disputes.
Daniel mentioned the writing work he used to do, and that's a domain where scope creep is particularly insidious because the deliverable is intangible. With a website, you can point to a screen and say "that's new." With a white paper, the client says "can you expand on this section" and it feels like a small ask, but expanding that section might mean new research, new interviews, new citations.
Writing is brutal for this. I've talked to freelance writers who say the single best thing they ever did was define the revision process in excruciating detail. Not just the number of rounds, but what constitutes a round. If the client sends feedback in seventeen separate emails over three weeks, is that one round or seventeen?
The answer is: that's one round if you define it that way. You can say in the contract: "A revision round consists of all feedback submitted within a seven-day review period. Feedback submitted after that period constitutes a new round." Now the client has an incentive to consolidate their feedback instead of dribbling it out.
Here's a subtle point that Daniel alluded to — the difference between being rigid and being clear. He said he didn't want to be the guy who says "you get precisely thirty minutes a week for calls and two revisions and that's it." But he became that guy because the alternative was being exploited.
The distinction is between being rigid and having boundaries. Rigid is arbitrary. Boundaries are principled. If you can explain why the boundary exists — "I limit calls to thirty minutes because I do my best work in focused blocks, and context switching kills my productivity" — most reasonable clients will respect that.
The unreasonable ones won't, and that's useful information. If a client pushes back on reasonable boundaries during the contract negotiation, they're telling you who they are.
Let's talk about intellectual property and ownership, because this trips people up. In most freelance contracts, the client owns the work product. That's standard and expected. But there are nuances.
The big one is: when does ownership transfer? The standard language is "upon full payment." Not upon delivery, not upon approval — upon full payment. If the client hasn't paid you, they don't own the work. This is your leverage.
Then there's the question of tools and processes. You might build a custom framework or a set of scripts or a methodology while working on a client project. Who owns that? If the contract says "all work product," does that include your internal tools?
This is where you carve out "pre-existing intellectual property" and "independently developed tools." You're not giving the client ownership of your entire toolkit just because you used it on their project. A good contract distinguishes between the deliverable — which they own — and the means of production — which you own.
Another payment term worth discussing: late fees. Net thirty with a two percent monthly late fee is common. Does anyone actually enforce this? In my experience, not often, but its presence in the contract changes behavior. Clients who know there's a late fee pay on time.
It's a signal. It says "I take payment seriously." And if you do have to enforce it, you have the contractual basis to do so. Without it, you're just sending increasingly awkward emails asking where your money is.
Daniel asked about the minimal viable client load, and I want to circle back to that with a point I don't think gets made enough. The number of clients isn't just about risk mitigation. It's about pricing power.
Say more about that.
When you have one client, they know they're your only client. Even if you don't tell them, they can sense it. You're always available. You respond to emails in minutes. You never have scheduling conflicts. And that gives them leverage, consciously or unconsciously, to push on rates and terms.
Whereas when you have four or five clients, you're genuinely busy. You're not available for a last-minute call on a Friday afternoon because you're working on someone else's deadline. That scarcity makes you more valuable, not less. It's counterintuitive but true.
The client who has to book time with you a week in advance values that time more than the client who can get you on the phone in five minutes. Human psychology doesn't change just because we're talking about business.
There's a related point about rate-setting. When you have multiple clients, you have real market data. You know what different clients are willing to pay. You can test rate increases with new clients before applying them to existing ones. You're not guessing — you're pricing based on evidence.
Let's talk about retainers, because Daniel mentioned them as a potential trap but they're also a useful tool when structured correctly. A retainer is essentially a client prepaying for a block of your time or a set of deliverables each month.
The danger is the retainer that's really a salary in disguise. The client pays you a fixed amount monthly, and in exchange you're expected to be available whenever they need you, for whatever they need. That's not a retainer — that's a job with worse tax treatment.
A proper retainer specifies what the client gets for their money. X hours per month, Y deliverables, Z meetings. Anything beyond that is billed separately. And — this is crucial — the hours don't roll over. If they don't use their allocation in a given month, they lose it. Otherwise you're just building up an unmanageable backlog of owed work.
The retainer should be paid in advance. You're not invoicing at the end of the month for work already done. The client pays on the first, and that buys them your availability for the month ahead. If they don't pay, you don't work.
This is also where a "use it or lose it" clause actually serves the client's interests, counterintuitively. Without it, clients let work pile up, they don't prioritize, and then six months later they want everything done at once. The monthly reset forces them to engage consistently.
I want to talk about the contract negotiation itself, because Daniel mentioned the Microsoft scenario — you send your contract, they send back "we're not using your contract." How do you handle that?
You read their contract very carefully, and you focus on the clauses that actually matter. You're not going to win on governing law or indemnification or most of the boilerplate. But you can absolutely negotiate scope, payment terms, kill fees, and revision windows. Those are business terms, not legal terms, and business people can override legal on those.
You look for the landmines. Non-compete clauses are the big one. A lot of corporate contracts have broad non-compete language that would prevent you from working with anyone in their industry. For a freelancer, that's existential. You need to strike that or narrow it dramatically.
Intellectual property assignment is another one. Some contracts have language that assigns not just the deliverables but anything you create during the engagement, even if it's unrelated. You need to narrow that to "work product created specifically for and paid for by the client.
Here's a practical tip: when you're negotiating with a large organization, don't send a marked-up contract as your first move. Send an email with three or four bullet points: "These are the areas where I'd like to discuss modifications." It's less confrontational and it lets the business stakeholder go to legal with specific asks rather than a redlined document.
That's good. It frames the conversation as problem-solving rather than a legal battle. "Here's what I need to make this engagement work" lands differently than "here are my proposed changes to section four point two.
Let's talk about the deposit question more concretely, because Daniel asked specifically about this. When do you ask for a deposit, how much, and how do you handle clients who resist?
For new clients, I'd say fifty percent up front is standard for project work. For ongoing retainer work, first month in advance. If the client resists, you have a conversation about why. Sometimes it's a cash flow issue on their end — they have a budget cycle, they need an invoice to trigger payment, whatever. Those are solvable problems.
Sometimes the resistance is a red flag. A client who won't pay a deposit is often a client who doesn't intend to pay on time — or at all. I've heard too many stories of freelancers who waived the deposit as a "gesture of good faith" and then spent six months chasing an invoice.
The other thing about deposits is that they solve the onboarding problem. When a client has paid fifty percent, they're committed. They're not going to drag out the kickoff process or delay providing the materials you need, because their money is already on the table.
For the freelancer, the deposit solves the cash flow problem. You can buy the tools you need, block the time, maybe even turn down other work because you've got money in hand. It de-risks the engagement from both sides.
I want to address something Daniel said about the asymmetry of negotiations. He's right that the power dynamic is real — a solo freelancer versus a corporate legal department is not a fair fight. But there's an asymmetry in the other direction too, and freelancers often forget it.
What do you mean?
The client needs the work done. They've gone through a sourcing process, they've evaluated candidates, they've chosen you. By the time the contract hits your inbox, they're already invested. They don't want to start over. That gives you more leverage than you think.
The cost of switching — even just the cognitive cost of finding someone new, briefing them, getting them up to speed — is real. You can use that. Not aggressively, not as a threat, but as a quiet source of confidence in the negotiation.
You're not being difficult. You're being professional. And professionals have standard terms. Doctors don't negotiate their copay. Lawyers don't waive their retainer. Why should freelancers be different?
Let's talk about the revision window specifically, because Daniel's story about the client coming back three months later is so common. The fix is simple contract language: "Revision requests must be submitted within X days of receiving the deliverable. After X days, the deliverable is deemed accepted.
The "deemed accepted" language is important. Without it, there's no closure. The project is perpetually open. With it, there's a clear point where the work is done and any further changes are new work.
What's your X?
It depends on the project. For a white paper, fourteen days feels right — it's enough time for multiple stakeholders to review and consolidate feedback, but not so long that the project goes cold. For a website or a software project, maybe thirty days because testing takes time.
You can build in an extension mechanism. "If the client needs additional review time, extensions are available upon request." That way you're not being rigid, but the default is closure, not indefinite limbo.
Another contract clause that doesn't get enough attention: the communication and feedback consolidation clause. This says that the client will designate a single point of contact who consolidates all internal feedback before sending it to you.
Oh, this is huge. Without this, you get feedback from seven different stakeholders, some of it contradictory, and you're expected to synthesize it all. You're not just doing the creative work — you're doing the client's internal politics for free.
It's a perfectly reasonable request. "To keep the project efficient and avoid conflicting direction, please designate one person to consolidate all feedback." Most clients will appreciate the structure. The ones who push back are telling you their organization is chaos, and you should price accordingly.
Let's talk about termination clauses. Every contract needs a clear termination process. How much notice? What happens to work in progress? What gets paid?
Thirty days' notice is standard for ongoing engagements. For project work, the kill fee we discussed earlier serves this function. But the termination clause should also address what happens to the work product if the engagement ends early.
The standard language is that the client pays for work completed up to the termination date, and they get the work product for what they've paid for. They don't get work they haven't paid for, and you don't hold completed work hostage. It's clean.
Here's a nuance: if you're working on something that's not divisible — say, a strategy document that's only useful when complete — you need language that addresses partial delivery. Otherwise you do eighty percent of the work, the client terminates, and they get nothing useful while you get paid for eighty percent, and everyone's unhappy.
That's where milestone-based work really shines. Each milestone is a complete, useful deliverable. If the engagement ends after milestone two, the client has two useful things and you've been paid for two things. No partial credit, no disputes.
I want to circle back to something Daniel said at the very beginning of his prompt — that the hardest thing to get right is contracts and scope. I think he's right, but I'd add that the reason it's hard is that it requires you to think about failure modes before anything has gone wrong.
When you're excited about a new project and the client seems great and everyone's optimistic, sitting down to write a contract that anticipates non-payment, scope creep, and early termination feels almost hostile. It feels like you're planning for the relationship to fail.
The counterintuitive thing is that clear contracts make relationships better, not worse. When expectations are explicit, there's less room for disappointment and resentment. The client knows what they're getting. You know what you're delivering. There's no subtext.
I'd go further and say that the contract conversation is a relationship-building exercise. When you talk through scope and revisions and payment terms, you learn how the client thinks. Do they push back on everything? Do they try to nickel-and-dime you? Or are they reasonable and collaborative?
It's an audition in both directions. You're auditioning for them, but they're also auditioning for you. And too many freelancers forget they're allowed to fire clients. If the contract negotiation reveals someone who's going to be a nightmare to work with, you can walk away.
That's the ultimate risk mitigation, isn't it? Having enough clients that you can afford to say no to a bad one. Which brings us right back to where we started — the minimal viable client load.
Three minimum, four to five ideally. No single point of failure. Contracts that specify scope, revisions, payment terms, and termination. Deposits up front. Change orders for anything outside scope. And the confidence to enforce all of it because you're not dependent on any one client.
The thing I'd leave listeners with is this: none of this is about being difficult or rigid. It's about being professional. The best clients — the ones you actually want to work with — will respect clear terms. They run businesses too.
The clients who bristle at reasonable boundaries are the ones who were planning to take advantage of you. They're self-identifying.
Now: Hilbert's daily fun fact.
Hilbert: In the 1980s, researchers discovered that cuttlefish camouflage patterns produce acoustic signatures distinct enough that sonar can distinguish a cuttlefish mimicking sand from one mimicking coral, even when the visual match is perfect to the human eye.
Hilbert: In the 1980s, researchers discovered that cuttlefish camouflage patterns produce acoustic signatures distinct enough that sonar can distinguish a cuttlefish mimicking sand from one mimicking coral, even when the visual match is perfect to the human eye.
Cuttlefish are acoustically committed to their disguise.
If you're freelancing or thinking about it, get your contracts in order. It's not the fun part of the work, but it's the part that keeps you solvent. This has been My Weird Prompts. Thanks to Hilbert Flumingtop for producing. Find us at myweirdprompts.We'll be back soon.
See you then.
This episode was generated with AI assistance. Hosts Herman and Corn are AI personalities.