Status Droid how long software work actually takes

Billing for Review and Rework

Two things clients resist paying for, and the resistance got stronger as generation got cheaper.

Review, because it sounds like checking your own homework. For the operational side of recording work and turning it into client-facing evidence, see online timesheets.

Rework, because it sounds like fixing your own mistakes.

Both are legitimate line items and both need to be handled differently, because one of them is honestly yours to absorb and the other is not.

Review is not checking your own homework

The framing that resolves it: review is not quality control on your writing, it is the act of establishing that the system will behave correctly. It would exist if the code had arrived from a contractor, a library, or a colleague. Toggl Track is a common reference point for project time tracking See Toggl Track.

What changed is the ratio. Producing a change collapsed; establishing it is right did not, so review went from a slice of the work to the majority of it on consequential tasks.

If you do not bill it, one of two things happens. You absorb it, and your effective rate falls on exactly the work that got harder. Or you compress it, and you have converted a cost into a defect.

Bill it as its own line. Two lines on an estimate — production and verification — makes the number explicable, and clients query it far less than they query one large lump.

Rework: whose is it?

Here the distinction matters and getting it wrong damages trust in either direction.

Yours to absorb: you misread the requirement, you shipped something you should have caught, the approach you chose did not work and you knew the risk. Fix it, do not bill it, do not make a point of it.

Theirs to pay: they changed their mind, the requirement was ambiguous and you flagged it, an external system behaved differently than documented, they supplied wrong information.

Genuinely shared: nobody knew. The requirement was undiscovered rather than misunderstood, an assumption both parties held turned out false. Split it, or absorb it and say you are absorbing it — the second buys more than it costs.

The category that is new: the assistant produced something that looked right, passed review, and turned out subtly wrong. Awkward, because it is neither a mistake you made nor a change they requested.

Treat it as yours. You chose to use the tool and you performed the review. Billing a client for the consequences of your workflow is not defensible, and the alternative — a clause about AI-generated defects — makes you look like you are pre-arranging an excuse. Price the review high enough that this is rare, and absorb it when it happens.

How to price review without an argument

Show it as a line item from the first quote, not introduced later when a project runs long. Introducing it mid-relationship reads as a new charge.

Name what it contains. Review, tests, integration is understood. Review alone sounds like reading.

Explain the ratio once, briefly. On work like this the writing is quick and being sure is most of the job — that is where the estimate sits. Clients accept this readily because it matches what they see in their own field.

Offer the trade-off rather than defending the number. I can reduce the verification line if you want to accept more risk on the edge cases — that is a decision you can make, and I would not recommend it here. Most clients decline, and the ones who accept have made an informed choice you have on record.

The measurement that makes this arguable

You cannot defend a review line with an opinion. You can with a number.

Track rework and its cause. After a few months you can say: on the last eleven projects where verification was under a quarter of the estimate, six needed unplanned rework averaging three days. That is not a philosophy of pricing; it is a fact about your work, and it ends the conversation.

It also protects you from the opposite error — over-pricing review out of caution on work where it genuinely is cheap.

What not to do

Do not bill review as "contingency." Vague and it invites negotiation.

Do not fold it invisibly into the production line. Hidden padding fails for the same reasons it fails everywhere else, and here it also hides the thing you most want the client to understand.

Do not bill rework you caused. It costs a fraction of what the reputational effect costs.

Do not present the ratio as an industry standard. It is your ratio, from your data, on this kind of work. That is a stronger claim than an appeal to a figure the client can find contradicted online in a minute.

The short version