---

title: "Having money conversations"

module: 7

module_title: "Difficult Conversations"

order: 7

access: "paid"

summary: "How to discuss pricing, change orders, and budget overruns as neutral information rather than confrontation, without apologizing for your rates or absorbing out-of-scope work silently. Includes scripts for presenting pricing, responding to sticker shock, raising change orders, and proactive budget check-ins."

related:

• "managing-scope-creep-conversations"
• "setting-vs-managing-expectations"
• "delivering-bad-news-effectively"
• "building-long-term-relationships-vs-transactional"

---

Having money conversations

I once avoided raising a change order for three weeks because I didn't want the conversation to feel awkward. By the time I brought it up, we'd already done $12,000 of out-of-scope work. The client was blindsided. Not because the work wasn't valuable, but because nobody had told them it would cost extra until after it was done.

The money conversation I was trying to avoid became ten times worse because I avoided it.

Why most of us are bad at this

If you came up through technical or creative work, you probably spent years building skills that have nothing to do with discussing pricing. Nobody teaches you how to present a budget, respond to "that's more than we expected," or raise a change order without feeling like you're nickel-and-diming someone.

So we avoid it. We absorb out-of-scope requests because it's easier than having the conversation. We undercharge because naming a real number feels scary. We send invoices without context and hope nobody questions them. We treat money as this unpleasant thing sitting next to the work, instead of a normal part of the professional relationship.

The problem is that avoidance doesn't make money conversations go away. It makes them worse. Unspoken assumptions about cost build up like pressure, and when they finally surface, the conversation is about broken trust instead of dollars.

How I think about this

Money is information, not confrontation. When you tell a client "this will cost $5,000," you're giving them information they need to make a decision. You're not asking them for a favor. Treating pricing as neutral information, the same way you'd communicate a timeline or a technical recommendation, changes how the conversation feels for everyone.

Separate the value conversation from the price conversation. Before you talk about what something costs, make sure the client understands what it's worth. "This integration will save your team about 10 hours a week of manual data entry" lands differently if you say it before "the integration will cost $8,000" instead of after.

Change orders should be boring. If scope changes are treated as unusual events, every one feels like a conflict. But if you establish early that scope changes are normal, expected, and handled through a simple process, they become routine. "Hey, this is outside the original scope. Here's what it involves and what it costs. Want us to proceed, or should we push it to a later phase?" That should feel as ordinary as a status update.

Never apologize for your pricing. Hedging language like "I know this might seem expensive" or "I wish I could do it for less" undermines your own value. State the price. Explain what it includes. Let them decide. If they push back, have a conversation about scope, not about whether your rate is justified.

Be specific about what money buys. Vague pricing creates vague expectations. "$15,000 for Phase 2" invites questions. "$15,000 for Phase 2, which includes the payment integration, email notification system, and admin dashboard, with two rounds of revisions and browser testing" leaves much less room for misalignment.

What this looks like

Presenting initial pricing

After a discovery process:

"Based on what we've discussed, here's how I'd break this down. The core build, everything in the requirements doc, comes to $42,000. That includes design, development, testing, and two weeks of post-launch support.

There are two optional items we talked about: the advanced reporting dashboard at $8,000 and the third-party shipping integration at $6,000. Both are useful, but neither is required for launch. We could add them in a second phase if budget is a concern.

I'm happy to walk through any of these line items if you want more detail on what goes into the numbers."

Responding to "that's more than we expected"

Client says the number is higher than they budgeted:

"I hear you. Let's talk about what's driving the cost and see if there's a way to get you what you need within your range. A couple of options: we could reduce the initial scope to the core features and add the rest later. That would bring Phase 1 down to around $28,000. Or we could simplify the design system, use more standard components instead of custom ones, which saves about $6,000.

What matters most to you in the first version? That'll help me figure out where we can flex."

Raising a change order

Mid-project, the client asks for something outside the original scope:

"That's a good idea. I want to flag that it's outside the current scope so we handle it cleanly. Adding the user roles feature would take roughly 3-4 days and cost about $4,800.

Two ways to handle it: we can add it to the current phase, which would push the timeline by about a week and increase the project total. Or we can note it for Phase 2 so it doesn't affect the current delivery date.

Either way works from our end. What's your preference?"

The budget check-in

Midway through a project:

"Quick budget check-in since we're at the halfway mark. We've used about 55% of the project budget, which is right on track. The one thing I'm watching is the API integration, which has been more complex than expected. If it continues at this pace, it might push us $2,000-$3,000 over on that line item. I'll know more by next week.

Wanted to give you a heads up now rather than surprise you at the end. I'll include budget tracking in the weekly updates from here on out."

What makes money conversations go wrong

Waiting too long to discuss cost. The longer you wait, the more emotional the conversation becomes. A change order raised immediately is information. A change order raised after the work is done feels like a trap.

Discounting before they ask. Some people pre-emptively lower their price because they're anxious about the reaction. This trains clients to expect discounts and tells them you didn't believe in your own number.

Being vague about what's included. If the scope of work is ambiguous, every cost conversation becomes a negotiation about what was "supposed to be" included. Specificity in the initial agreement prevents most of this.

Making it personal. Money conversations go sideways when someone feels judged. "You can't afford this" is different from "Let me adjust the scope to fit your budget." Same outcome, completely different experience.

Absorbing costs silently. Doing out-of-scope work for free might feel generous, but it sets a precedent. The client doesn't know they're getting something extra. They just think it's what they paid for. When you finally do raise a change order, they're confused about why this one costs money when similar requests didn't before.

Getting better at this

Practice the words out loud. If saying "this will cost $10,000" makes you uncomfortable, practice it until it doesn't. Seriously. Say it to yourself, say it to a friend. The discomfort is about unfamiliarity, not about the number being wrong.

Document scope in detail before work starts. The clearer the initial scope, the easier every money conversation becomes. Include what's in scope and what isn't. When someone asks for something outside the list, the conversation is "that's not in the current scope" rather than a negotiation.

Track your time even on fixed-price projects. You need to know where your budget is going so you can catch overruns early and have informed conversations. Surprises come from not tracking, not from the work itself.

Keep a change order template. Make the format routine. Date, description of the change, estimated hours, estimated cost, impact on timeline, approval needed. When the process is standardized, individual change orders feel less confrontational.

Separate your self-worth from your pricing. A client saying "that's too expensive" is not saying you're not good enough. They're saying the number doesn't fit their budget. These are different things. Keeping them separate makes the conversation about problem-solving instead of ego.

How this connects

Money conversations sit underneath a lot of what this collection covers. Managing scope creep is a money conversation. Setting expectations involves cost. Delivering bad news sometimes means delivering budget news. And building long-term relationships requires being someone who handles money honestly, because clients remember who was upfront about cost and who surprised them.

Things to try

• Next time you present pricing, state the number without hedging language. No "I think" or "roughly" or "I hope this works." Just the number and what it includes.
• Add a scope exclusions section to your next proposal. List specific things that are not included.
• The next time scope changes mid-project, raise it within 24 hours. Don't wait to see if it's "big enough to mention."
• Practice the sentence: "That's outside the current scope. Here's what it would involve."
• Include budget status in your next weekly update, even if everything is on track.

I used to think being good at client work meant being good at the work itself. And that's part of it. But some of the most important moments in a client relationship happen when you're talking about money, and doing it with the same clarity and directness you bring to everything else is what separates a vendor from a trusted partner.

Template: Change Order Message

Use this when: a client asks for something outside the original scope mid-project and you need to name the cost immediately, without drama.

Channel: Slack message

```template

That's a good idea. I want to flag that it's outside the current scope so we handle it cleanly rather than letting it blur the numbers later.

[THE REQUEST] would take about [TIME ESTIMATE] and cost roughly [$ AMOUNT].

Two ways to handle it:

• Add it to the current phase — pushes the timeline by about [TIME] and raises the project total to [$ NEW TOTAL].
• Slot it into [LATER PHASE] so it doesn't touch the current delivery date.

Either works on my end. What's your preference?

```

Template: Responding to "That's More Than We Expected"

Use this when: you've presented a price and the client says it's over their budget, and you want to flex scope instead of discounting your rate.

Channel: Call script

```template

Acknowledge without flinching:

"I hear you. Let's talk about what's driving the cost and find a way to get you what you need within your range."

(don't apologize for the number, and don't drop it reflexively)

Offer scope options, not a discount:

"A couple of ways we can flex:

• We could hold to the core features and add [THE REST] in a later phase. That brings [PHASE 1] down to around [$ AMOUNT].
• Or we could simplify [SOMETHING — the design system, custom components], which saves about [$ AMOUNT]."

Put the decision in their hands:

"What matters most to you in the first version? That'll tell me where we can flex without giving up the things you actually care about."

(pause — let them tell you their priorities, then shape the scope around them)

```