Client Management
How to Organize Freelance Projects and Client Tasks (Your Task App Isn't the Problem)
Most freelance project management advice is really software advice, which is why it doesn't help. The problem isn't which app holds your tasks. It's that the task list and the thing you're getting paid for have drifted apart.
A project is three documents, not a task list
Before any tasks exist, a client project should have three things written down. A scope of work says what's included and, just as importantly, what isn't. A roadmap or milestone plan says in what order and by when, which is what turns an intimidating brief into something both sides can track. A change log (a running record of change requests) captures everything added after the scope was agreed. Tasks are downstream of those three; they're the breakdown of work that has already been defined and priced. Projects that start with a task list instead tend to grow sideways, because a task list has no concept of what was in scope, so adding one more task never feels like a change.
Structure tasks by milestone, because that's how you get paid
Group tasks under the milestone they deliver rather than by type of work or by week. The reason is practical rather than aesthetic: milestones are usually what your payment schedule keys off, so a milestone-structured project answers "can I invoice yet?" directly, without you reconstructing progress from a flat list. It also makes partial completion legible to the client: "milestone two is three tasks from done" is a status update; "I've finished fourteen of twenty-two tasks" isn't. Keep milestones small enough that one lasts two to four weeks. Longer than that and the gap between invoices starts to hurt cash flow, which is the problem milestone billing exists to solve in the first place.
Every "can you just also" becomes a change request
Scope creep almost never arrives as a large request. It arrives as a series of small ones, each individually too minor to feel worth a conversation, and the cumulative total is what you end up absorbing. The fix is a rule with no judgement call in it: anything not in the signed scope of work gets written up as a change request with its own price and timeline impact, however small, before it gets scheduled. Most clients approve most of them. The point isn't to refuse the work, it's to make sure the work is visible and paid. It also protects the schedule, because a change request that says "+3 days" is how a client learns that additions move the deadline, without you having to argue for an extension later.
Choosing a tool: what actually matters
There's no single right tool, but there is a right test: can this thing hold the scope, the milestones, and the change log alongside the tasks, and connect them to the client and their invoices? A general project management app handles tasks well and documents poorly. A notes app handles documents well and tracks nothing. Whatever you pick, the failure mode to avoid is splitting one project across three tools where none of them shows the whole picture. That's the setup where scope drifts unnoticed, because no single screen ever puts the agreed scope next to the work actually being done.
| Setup | Handles well | Falls down on |
|---|---|---|
| General PM app (tasks, boards) | Task tracking, deadlines, collaboration | Scope documents, contracts, invoicing links |
| Notes or docs app | Scope, briefs, meeting notes | Task state, due dates, billing status |
| Spreadsheet | Quick ad-hoc tracking, custom views | Documents, relationships, multi-project scale |
| Client workspace with documents | Scope, roadmap, change requests and invoices per client | Deep task features like dependencies or sprints |
Frequently asked questions
- How detailed should a freelance scope of work be?
- Detailed enough that a disagreement about whether something is included can be settled by reading it. In practice that means deliverables with counts (three page designs, two revision rounds) and an explicit exclusions list. The exclusions list does most of the work: it's what you point at when a request arrives that both sides genuinely assumed differently.
- Should clients have access to my project tracker?
- Usually not the raw one. Clients need milestone status and what's blocked on their input, not your internal task breakdown, and the full view invites comment on how you work rather than what you deliver. A short status update against the agreed milestones, on a fixed cadence, covers what they actually need.
