Commit Messages for Client Work

Every commit I write comes with a message that says what changed and why. Before I wasn’t applying that discipline to client work, and I should have.

Code teaches you this fast. Something breaks three weeks after a change, you open the log, and the message just says “fix.” Now you’re rebuilding the reasoning from memory, trying to work out what you were thinking and whether the change was supposed to do what it did. Multiply that across a dozen clients and a year of decisions, and you’re mostly guessing.

The same failure with a client

Now picture it with a person instead of a codebase. You raise a retainer on a phone call, everyone agrees, and nobody writes down why. Two months later, neither of you can say for sure whether that increase covered a new deliverable or was just a price change, and you end up renegotiating something you’d already settled.

That kind of disagreement stings because it’s completely avoidable. It isn’t really a client problem. It’s the same failure as untracked code, where changes happen and nobody can say why.

Two people can leave the same call remembering two different agreements, and neither of them is lying.

I’ve seen how that goes, and the worst part is that both people are being honest. Memory fills gaps with whatever favors the person remembering. A written note doesn’t have that problem.

What a client commit looks like

Client accounts get the commit treatment now. Whenever something changes, I write down what changed, why, and what it looked like before. A budget moved from one channel to another. A deliverable added to the scope. A report rebuilt after a source changed. Each gets a short entry with a date.

The “what it looked like before” line is the one I added last, and it turned out to carry the most weight. A change with no record of the prior state is hard to reason about later, and it’s the first thing anyone forgets.

It costs two extra minutes per change, and it has already prevented a few disagreements that were really just two people remembering the same call differently. I’ll take that trade every time, and I wish I’d started earlier.

Why it matters beyond the arguments

The log also makes the work easier to hand over. Anyone who opens the history can see how the account got to where it is, instead of needing me to explain it. That connects to something I care about when I build for small businesses, which is that the work should still make sense to the owner without me in the room.

I picked the habit up from writing code, and it fixed a problem in a part of the business that has nothing to do with code. I’m a little embarrassed it took me this long to connect the two, since I was writing careful commit messages the whole time and handling client changes by memory.

What’s a habit from a completely different field that ended up fixing how you run your business?