Project management for freelance designers: manage the wait, not the task list

For a freelance designer, the thing that needs managing is not your task list. It is the queue of work standing still because somebody else hasn't sent the logo files, hasn't answered the question about the pricing page, hasn't signed off on round two. Team project software solves assignment and dependency problems between people who share a payroll. You have neither problem. You have four projects that are all technically "in progress" and none of them moving today.

So build the system around one question: who am I waiting on, for what, and since when? Task boards, Gantt views and sprint velocity are decoration on a team of one.

Why team tools mis-fit a one-person studio

Assignment is the core feature of almost every tool in this category, and for you it is dead weight — every card has the same assignee. Capacity planning assumes a pool of people to move work between. Dependency chains assume the blocker is another workstream, not a client's marketing manager who is on holiday until the 24th.

What survives the translation to solo work is narrow: a place to see external blockers with names and dates, a structured way to receive files and approvals, and an archive you can search in eighteen months when the client asks why the footer looks like that. Most feature comparisons rank tools on the parts you will never touch. If you are evaluating candidates, it is worth reading a feature list against your own workflow first — what actually matters in project management software for web designers is a different set of criteria than what a ten-person product team needs.

The second mis-fit is subtler. Team tools are built on the assumption that everyone with a stake in the project has an account. Your clients do not, will not, and should not have to. Any workflow that depends on a client logging in to a system to approve something has a failure point in it that you will discover on a Friday.

The blocked-time ledger: count the wait before you buy anything

Before you change tools, measure the thing you are trying to fix. For each open project, keep two counters: days you actually touched the work, and days it sat waiting on a named other person. Also record the longest single unbroken wait.

Here is a fictional but unremarkable quarter for a solo designer running four projects:

Thirty working days against sixty-five blocked days is a work ratio of about 32 percent. That single number is a better diagnostic than any feature comparison, and here is the rule I use with it: below roughly 40 percent, the fix is your intake, not your tooling. Between 40 and 60 percent, a structured portal for briefs and approvals can pay for the setup time. Above 60 percent, clients are not your constraint — your calendar is, and a project tool will not give you more hours.

The last column matters as much as the totals. One twelve-day wait and twelve one-day waits produce the same ledger entry and describe opposite problems. A long single block usually means you asked for something with a lead time too late — photography, legal sign-off, a third-party API key. A string of one-day waits usually means the round trip itself is the problem: question, reply, follow-up question, reply, each one costing a day because it travels by email.

Three lanes, two hard limits

Three states cover freelance work: Queue (signed, not started), In production (you are the bottleneck), Waiting (someone else is).

Two limits keep it honest.

• Two in production. Holding two visual systems in your head on the same day is already expensive; the third one gets the version of you that is thinking about the other two.
• Four in waiting. This one is derived, not arbitrary. Each waiting project needs roughly one deliberate follow-up touch per week — re-read the thread, send a specific chase with a date in it, update the card. Budget a 45-minute weekly follow-up block and you can service about four projects properly. A fifth means one of them silently stops getting chased, and it is always the one with the politest client.

When a fifth project wants to enter Waiting, something closes or the follow-up cadence stretches to fortnightly — decide which, deliberately, rather than discovering it in November.

One formatting rule makes the Waiting lane useful: no card may say "waiting on client". It says "Waiting on Marta for the trade-licence PDF and the two team photos, requested 4 August, chased 8 August." A state without a name and a date is not a state, it is a feeling.

Five objects your setup has to hold

Whatever you use — a spreadsheet, a database tool, a portal, index cards — it needs to store five things and connect them:

1. Project — with a fee and a link to the agreed scope.

2. Deliverable — countable. "Six page designs, desktop and mobile," not "the website."

3. Blocking input — what you need, from which named person, requested on which date, in which format.

4. Approval — what was approved, by whom, on what date, in writing.

5. Money trigger — which event releases which invoice.

Then run the one-view test: open your setup and try to answer which deliverables are currently blocked, on whom, and since when without opening a second application. If you need a second tab, you own a task manager, not a project system. Most freelancers fail this test not because their tool lacks a field but because the answer lives in an inbox.

The same test applies at the other end of the project, where deliverables leave rather than arrive; the file-organisation half of that problem is covered in design handoff tools.

A 30-point fit test — score the tool you already use first

Six criteria, zero to five points each. Score honestly, and score your current setup before you score any candidate.

Read the total like this: 17 or below, keep the spreadsheet and the folder convention and spend the effort on intake instead. Between 18 and 23, adopt it only if you can name a workaround for each of your two lowest-scoring criteria. From 24 up, the migration is probably worth it.

The step people skip is scoring what they already have. Run it and you often find the current setup lands at 19 and the shiny replacement lands at 20 — a fortnight of migration to buy one point.

Free plans: what to confirm before you build on one

Plan contents and limits change, and they change without announcement, so treat anything you read about a plan — here or in a comparison post — as a claim to verify on the vendor's own pricing and limits pages, with the date you checked it written next to your notes.

Six things to look up specifically:

• Guest or collaborator seats — whether people outside your account can participate at all, and whether that counts against a seat.
• Per-file size cap, not just total storage. Check it against your actual worst case: a packaged design file, a client's uncompressed video, a scanned brand manual.
• Active project count, and what happens to project number four.
• Retention after a downgrade — whether files stay readable if you stop paying.
• Export — whether it exists on the tier you are on, or only above it.
• Client-facing links — often the one feature that separates the free tier from the paid one, and the one you need most.

The failure mode is predictable: free-tier limits surface at the worst moment, which is the afternoon a client finally sits down to upload the brand assets and hits a wall you never tested.

The switching math nobody budgets for

Migrating a live project is not a data export. It is re-entering scope, deliverables and dates, re-uploading current files, and rebuilding the conventions that were in your head. Budget about 25 minutes per active project. With six live projects, that is roughly two and a half unbillable hours, followed by about two weeks in which you still look in the old place first.

Three rules follow:

• Switch between projects, not mid-round. A tool change during a revision cycle costs you the thread of what was already agreed.
• Once per twelve months at most. More often and you are managing your tooling rather than your projects.
• If the reason you want to switch is "my clients are slow," stop. A different interface will not make Marta send the PDF.

Where freelance design projects actually break

Four failure modes account for most of the damage, and each has an early tell.

The brief that only exists in a call. Early tell: in week two you catch yourself writing "as discussed" in an email. Nobody can approve against a conversation, so round three becomes an argument about something that was never written down.

Approval by emoji. A thumbs-up in a chat app, then a change request in week nine from the person who never saw it. Early tell: you cannot say out loud who approved the homepage and on what date.

Files arriving in the channel you don't archive. The logo comes in as a phone photo of a printout, in a chat you will lose access to when the client changes agencies. Early tell: you have ever asked a client to "just resend that."

The undefined invoice trigger. The contract says the balance is due on final approval, and final approval was never an event with a date attached. Early tell: an invoice sitting unsent because you are not sure the project is finished.

Charging for coordination without guessing at rates

Rate questions get answered with survey numbers that are stale by the time you read them, so measure your own instead. Take three finished projects and add up the hours that went into intake, chasing, revision admin and handoff. Divide by the billable hours. That is your coordination overhead ratio.

Above roughly 25 percent, raising your fee is the third fix, not the first. Overhead scales with ambiguity: on a vaguely specified project, a higher price buys you a more expensive version of the same chasing. The order that works is tighten the brief, move the waiting into one structured place, then reprice — and if the fee needs a conversation, how to set clear expectations without surprise costs is the version of that discussion clients accept.

Questions that come up

Is a spreadsheet enough?

For up to about three concurrent projects with one stakeholder each, yes — a sheet, a folder convention and a weekly calendar block will hold. The thing that breaks first when you add a fourth project or a second stakeholder is not the task list. It is the approval trail: with two people able to approve and neither of them writing it down, you lose the ability to say what was agreed.

What about the "five C's of project management"?

The acronym circulates with different word sets depending on who is teaching it, so check what your source actually means by it before building anything on the phrase. Whichever list you find, they describe coordination between people. Solo, it collapses into two questions: what is countable in this project, and who owes me what by when.

Should the client see my board?

Show them one lane, not three. A client-facing view should list what you are waiting on from them, with names and request dates, and nothing about your production sequence. The moment clients can see your other work in progress, you start getting asked why theirs isn't first.

Where none of this applies

Single-client retainer work is the exception. When one company sends you steady work and you already have a standing weekly call, blocked time barely exists as a category, and lanes and WIP limits add ceremony to a problem you do not have — a recurring checklist and a shared folder will do.

For everyone else, start with the ledger. Run it for one month on whatever you already use, then read the work ratio. If it comes back under 40 percent, the next thing to fix is how projects come in, not what you manage them with.