Why 'Done' Is a Dangerous Word in Client Work

A developer tells a client the login page is done. The client opens the site the next morning and the login page is broken. Nobody lied. They were both right, using two different definitions of the same word.

The developer meant: I wrote the code and it works on my machine. The client heard: I can use this now. Between those two sentences sit four stages nobody named out loud — and every one of them is a place where an invoice can turn into an argument.

The word does six jobs and none of them well

In a shop where the person who builds the thing is also the person who owns it, 'done' is loose and harmless. You built it, you use it, you know exactly what state it's in. Client work removes that shortcut. The builder and the buyer are different people, in different rooms, looking at different things, and 'done' has to travel between them carrying all the information a status update should carry. It can't. It's one word.

Here's what it's usually standing in for, in the order the work actually happens:

1. Coded — the feature exists in a branch. Nobody outside engineering has seen it run.
2. Locally tested — it worked on the developer's machine, under conditions the developer chose.
3. Deployed to staging — it's running somewhere the client could look at it, if someone told them to.
4. Reviewed — someone on the client side actually opened it and formed an opinion.
5. Accepted — the client said, out loud or in writing, that it matches what was asked for.
6. Released — it's live, for real users, and the clock on the engagement can move to the next line item.

Six states. One word covering all of them. The gap between any two adjacent states is where the trust problem lives.

The invoice that goes out too early

Say a checklist item reads "Build checkout flow" and it gets marked done the day it's coded. The invoice for that milestone goes out that week, because the project tracker says done and the tracker is what billing looks at. Three days later QA finds that checkout silently fails for anyone using a gift card. The client has already paid for something that, by their own definition of done, wasn't finished. Now every future invoice gets a second look before it's approved, and the second look is slower than the work.

This is not a story about bad developers. It's a story about a status field that had one setting for six different truths, and a billing process that trusted the field.

The review that never happened

The opposite failure is quieter and it costs more over time. Work gets deployed to staging, the agency considers that a milestone hit, and everyone moves on to the next thing. The client never actually opens staging. Three sprints later, someone finally clicks through and finds four features that don't match what they asked for — not because the work was wrong, but because nobody reviewed it at the point where fixing it would have been a small conversation instead of a rebuild. "Deployed" got treated as "reviewed," and reviewed is the only stage that requires the client's actual attention, not just their access.

Staging existing is not the same as staging being looked at. An agency that tracks "deployed" as done is tracking their own effort. A client only cares about the stage that involves them.

Acceptance is a decision, not a milestone

The most expensive confusion is between reviewed and accepted. A client can look at something, say "looks good so far," and mean exactly that — so far, not finished, not signed off, keep going. If the agency records that as acceptance and invoices the milestone, the client didn't agree to what got billed. They agreed to what they saw at that moment, with the understanding that more was coming.

Acceptance needs to be a specific act, distinguishable from a comment. Not "the client seemed happy in the call" but a written yes to a specific, described state of the work. Anything softer than that is a review, and a review is not a contract.

What this looks like when the roles are actually separated

We build Team and Tricks around the fact that the person doing the work and the person paying for it are often not the same person, and they don't need the same view of a task's status. A checklist row can carry an attention marker — Question, Attention, Blocked — that says something is unresolved without forcing the whole task back to not-done. A Classic task can carry a written progress report instead of a binary flag, so "coded, not yet tested" is a sentence someone actually wrote, not an inference from a checkbox.

The part that matters most for client work is who gets to see and touch which of those stages. A client added as a guest sees only what's granted — a project, or specific tasks inside it — and by default can't read or write comments unless that's turned on for them. That's not a limitation, it's the point: it gives you a moment to decide when a client's review actually starts, instead of it starting automatically the second something is marked done internally. When a client does need to weigh in on something, they can raise it as a request rather than a task edit, and specific messages in that thread can be flagged for formal request approval — a real, timestamped yes, separate from a comment that just sounds encouraging.

None of that collapses six stages into one status field. It keeps them as what they are: a piece of code someone wrote, a thing someone looked at, and a thing someone agreed to. Those are three different facts, and only the last one should ever appear on an invoice.

The sentence to keep

"Done" is a fine word for a solo project, where the person who finishes the work is the only person who has to be satisfied with it. In client work it's doing the job of six different sentences, and whichever one the client hears is the one that ends up disputed. Say the actual stage. It costs one more word and saves the argument that shows up on the invoice.