Most freelancers lose their first year not on technical ability, but on client management. I fell into the same pit. Post-contract “let’s also add this” ambushes, last-minute changes, late payments, the same work redone three times as the brief shifted. Eventually I learned that expectation management starts long before you sign a contract.
First call: the filter
Not every potential client goes straight to a quote. The first call answers a different question: are we a fit? Warning signs for me:
- They deflect on budget. “Let’s evaluate the idea first, talk budget later” usually means no budget, or they’ll try to grind it down.
- “A small project” that turns out to be six months of work when described.
- “Other devs quit halfway” stories. Only hearing one side of that, the client’s communication style might be the problem.
- Pressure to “move fast”. The project is probably already past its deadline.
- “I need to call you now” for a non-urgent thing. If they manufacture urgency at the intro, they’ll do it the whole project.
Different signals, different responses. One flag means extra caution. Two flags means I raise the fee by 50%. Three and I say “I don’t think we’re the right fit” and decline.
Discovery: start with a written summary
Before any contract, I do a discovery call, then follow up with a written summary:
Hi,
Here are the notes from our call yesterday.
Let me know if anything is missing or wrong.
Scope:
- ...
Out of scope:
- ...
Timeline estimate: ...
Budget: ...
Payment plan: ...
If you approve, I'll send over the contract.This summary matters. “Actually, I also said X” stops being viable. If something was left out, this is the moment it gets added.
The contract: detail vs flexibility
Too detailed and it scares the client. Too loose and you have no protection. My standard structure:
- Scope of work (specific, what gets done)
- Out of scope (what won’t, as a firm boundary)
- Delivery date + milestones
- Payment plan (deposit + milestone-based)
- Change request process (revision policy)
- Intellectual property (who owns what)
- Cancellation terms
- Paid support window
The change request clause is especially important. “Any request outside scope will be treated as a new quote” in a signed contract blocks later pushback.
The deposit rule
First-time clients always pay a 30 to 50% deposit up front. A client who won’t is going to balk somewhere else down the line. I learned this the hard way: before I enforced it, every no-deposit job ended in payment trouble.
Work starts when the deposit lands. No deposit, no start. Simple rule.
During the project: a weekly update
I send one update on the same day every week (Friday evening for me):
- What I finished this week
- What’s planned for next week
- Blockers (if any)
- Decisions needing attention (if any)
The client sees progress without asking. It eliminates the “how’s it going?” emails.
Scope creep handling
I have a memorised response to every “and while we’re at it, could we also” sentence:
“Nice idea. It’s outside the current package but we can treat it as an add-on. Roughly X hours, about Y added cost, pushes delivery by Z days. Want me to send over a new quote?”
Framed politely, openly, with a choice, the client either accepts (new quote, paid) or drops it. I don’t quietly absorb it and do it for free.
Revision limits
Design projects get two revisions. Code projects get unlimited bug fixes but a fixed number of feature revisions. Without a clear limit, clients will iterate forever.
“This is revision number three, the contract includes two. Any further revision is billed hourly. Shall we proceed?” This sentence works.
Client education
It’s normal for a client not to know exactly what they want. A little education up front helps:
- What WordPress can and can’t do.
- When SEO starts paying off.
- How caching works.
- Why staging matters.
That education calms the client and pulls expectations to a realistic place.
After delivery: docs and support
At handover:
- A video walkthrough: “how to add content in the admin panel”.
- Written docs on important processes.
- Access credentials shared via a password manager.
- Support period: 30 days of free bug fixes, features excluded.
After the 30 days I offer a retainer (monthly maintenance package). About 60% of projects turn into retainers. Recurring revenue.
Parting with bad clients
Core principle: no work is worth making myself miserable. If a client is consistently toxic, habitually late on payments, or disrespectful, I finish the project and don’t take another. If it’s bad enough, the early termination clause kicks in: I invoice for what’s done, hand over documentation, and walk away.
The time and morale you lose to that kind of relationship outweighs any project it costs you.
Yearly review
Once a year I audit every active client:
- Is this relationship healthy?
- Is the rate current?
- What’s the real hourly yield?
- Do I want to continue?
Based on that, some clients get a price bump, some drop off the retainer, and some move to larger packages.
Takeaway
Freelancing is as much managing client relationships as it is doing good technical work. Written communication, clear scope, boundaries, regular updates, the ability to say no politely. Once these are in place, projects become both profitable and enjoyable. Managing expectations is a skill, and a learnable one.