What 8 Years Changed About How I Think About Rates

I was wrong about what a rate increase actually is. For years I treated it as a negotiation - a moment where I asked for more money and the client decided whether I was worth it. That framing put me in the wrong position every single time. The client became the judge, I became the petitioner, and the conversation started badly before either of us said a word.

What changed my thinking was not a single conversation. It was watching the same failure repeat across enough engagements to see the pattern clearly. The rate conversation fails almost always for the same structural reason, and it is not that the engineer lacks confidence or charges too little. It is that the engineer presents the rate change as a request instead of as information about a changed situation.

This is a postmortem of that failure mode - what breaks, how badly, and what actually holds up afterward.

Stage 1 - What Broke, and the Blast Radius

The triggering event is almost always the same: you send a message or open a call and tell the client your rate is going up. Maybe you give a percentage. Maybe you give a new number. The client goes quiet, or they push back, or they say they need to think about it and then ghost you.

The blast radius is larger than the lost contract. When a client leaves after a rate conversation, they leave remembering the friction, not the work. That matters because founders talk to other founders. A CTO who felt surprised by a rate jump will describe you as unpredictable to the next person who asks. You do not just lose one contract. You lose the referral that contract would have generated.

The wrong version of this conversation looks like this: you deliver a project, the client is happy, and then you send a message that reads roughly like a salary negotiation email. You list your experience, you mention inflation or market rates, and you name a new number. You are asking for a raise. The client did not hire an employee. They hired a contractor to solve a specific problem, and the framing of a raise does not map to how they think about the relationship.

The right version does not start with the rate at all.

Stage 2 - The Timeline of How It Actually Fails

Here is the sequence as it typically unfolds, in order, when the conversation goes wrong.

The engineer finishes a successful engagement. Delivery was solid. The client is satisfied. The engineer now feels this is the right moment to raise rates - which is correct in principle. Goodwill is at its peak. The mistake is in what happens next.

The engineer sends the rate increase as a standalone message, usually between projects, when there is no active work to point at. The client receives a number with no context about what changed. From the client's side, nothing changed. The work was the same. The engineer was the same. The only new variable is the price. So the client's natural question is: why?

If the engineer cannot answer that question with something concrete - not "my skills improved" but something the client can see and point to - the conversation stalls. The client is not being difficult. They are applying the same logic they use for any vendor relationship: if the product did not change, why does the price change?

The real cause of the failure is not the rate itself. It is the absence of a documented record of value delivered. The engineer kept no running log of what they shipped, what it replaced, or what it cost the client not to have it. When the rate conversation arrives, there is nothing to reference. The engineer is asking the client to remember value that was never made explicit.

This is the structural problem. The rate conversation is lost or won in the weeks before it happens, not in the moment it happens.

// Wrong: rate increase as a standalone ask
"Hi, I wanted to let you know my rate is going up to $X/hr starting next month."

// Right: rate increase as a natural outcome of a scoped conversation
"We finished the auth refactor last week. That removed the manual review step
your team was running every deploy. Starting on the API work next, my rate
for that scope is $X/hr - here's the breakdown of what's included."

The code block above is not about code. It is about the shape of the message. The wrong version presents a number. The right version presents a number inside a context that makes it legible.

Stage 3 - What Changed, and What Did Not Get Fixed

After enough failed rate conversations, the thing that actually changed was not how I asked. It was when and how I built the case, starting from the first week of an engagement.

A running value log does not need to be formal. It can be a private note updated after each delivery: what shipped, what it replaced, what the client said about it. When the rate conversation arrives, that log becomes the basis of the conversation. You are not asking the client to remember value. You are showing it to them.

The rate increase itself lands differently when it is tied to a scope change rather than a calendar event. A calendar-based increase ("my rate goes up in January") is arbitrary from the client's perspective. A scope-based increase ("the next phase involves [X], which is a different kind of work, and here is the rate for it") is logical. The client can follow the reasoning. They may still push back, but they are engaging with the reasoning, not reacting to a surprise.

If you are on retainer with a client, the increase conversation is easier because the relationship already has a structure. From One-Off Gig to Retainer: The State Change covers how to move a client from project-based work into that structure - which is worth doing before you need to raise rates, not after.

What did not get fixed: the impulse to have the rate conversation at the end of a project, when the work is done and the client's attention has moved on. The better window is at the start of the next scope, when the client is focused on what they need and you are in the position of defining how to deliver it. Scope definition is where pricing lives. That is the moment to name the rate, not after delivery.

Two other pieces in this cluster are worth reading alongside this one. Ask Who Reviews Your Work Before You Take the Job is about filtering clients before you are invested - which matters because some clients will never accept a rate increase regardless of how well you frame it, and it is better to know that before the first contract. And The "Can You Do It Cheaper" Message: A Receipt for Handling It Without Losing the Job or Your Rate covers the inbound pressure version of this same dynamic - when the client opens the pricing conversation instead of you.

The pattern across all three is the same: the engineer who controls the framing controls the outcome. Not always, and not completely - some clients will leave regardless. But the engineer who presents a rate as a natural consequence of documented value, tied to a defined scope, at the start of a new piece of work, loses that conversation far less often than the one who sends a number and waits.

The thing I was wrong about for years was thinking the rate conversation was about courage. It is not. It is about preparation. The courage part is easy once you have something concrete to say.

What does your current process look like for tracking value delivered during an engagement - and do you have anything to reference when the pricing conversation comes up?