When a client says your software proposal is too expensive

The proposal call has gone well.

The client agrees with the problem. They like the delivery plan. They ask sensible questions about the architecture and timeline.

Then the pricing slide appears.

“This is much more expensive than we expected.”

The founder starts explaining senior-engineer rates. The pre-sales lead offers a ten-percent discount. The delivery manager quietly calculates which parts of the estimate will now have to disappear without being removed from the promise.

That is how a price objection becomes a delivery problem.

When a client says your software proposal is too expensive, do not defend the number or reduce it immediately. First find out what the price is being compared with and which constraint is actually blocking the decision.

“Too expensive” is not one objection

The same sentence can describe five different gaps:

• Budget gap: the client cannot spend the proposed amount.
• Expectation gap: they expected a smaller scope or a different delivery model.
• Comparison gap: another proposal appears cheaper.
• Value gap: the outcome does not yet justify the investment.
• Approval gap: the person on the call cannot defend the price internally.

Each gap needs a different conversation.

If the budget is fixed, the team may need to reduce or phase scope. If the client is comparing two proposals, both sides need to compare assumptions, ownership, and exclusions—not only totals. If the decision-maker cannot see the business consequence, another discount will not repair the value gap.

Strong discovery reduces these surprises. The DEPTH framework for pre-sales discovery helps connect the proposed solution to the client's decision before the number arrives. When the objection still appears, use PRICE.

The PRICE framework for software proposal objections

PRICE gives agency founders, pre-sales engineers, and delivery leaders five moves for discussing price without becoming defensive or giving away delivery safety.

1. Pause the discount reflex

The first few seconds matter.

An agency founder may hear “too expensive” as rejection. A pre-sales engineer may hear it as a request to justify every technical decision. Both reactions move too quickly.

Start by acknowledging the gap without accepting an undefined conclusion:

“Understood. It sounds as though the proposal is above the range you expected.”

Then pause.

Not:

“We can probably reduce it by ten percent.”

The instant discount teaches the client that the original number was negotiable before either side understands why. It also leaves the full delivery expectation in place unless you explicitly change it.

A calm pause is not a pressure tactic. It creates enough room to diagnose the real objection.

2. Reveal what “expensive” is being compared with

Ask a question the client can answer without defending their position.

“Which part feels out of alignment: the total budget, the scope included, or the effort behind a particular workstream?”

Other useful questions include:

• “What range had you planned for this phase?”
• “Are you comparing this with another proposal or an internal estimate?”
• “Has the budget changed since discovery?”
• “Which outcome is hardest to justify at this investment?”
• “Is the issue the total cost or the amount required upfront?”

Do not fire all five questions. Choose the one that identifies the kind of gap.

Not:

“Compared to what?”

That question can be useful, but delivered alone it can sound like a challenge. Make the purpose collaborative:

“It would help to understand what you are comparing, so we can check whether the scope and responsibility are equivalent.”

3. Inspect what the numbers actually include

Two software proposals with different totals are rarely identical underneath.

Compare the elements that can change delivery:

• Discovery and requirement clarification.
• Design and user-flow validation.
• Integrations, migration, and data cleanup.
• Testing depth and supported devices.
• Security, compliance, and audit requirements.
• Deployment, monitoring, and handover.
• Post-launch warranty or support.
• Client responsibilities and required inputs.
• Assumptions that can trigger change requests.

Keep the comparison factual. Do not attack the cheaper provider or imply poor quality without evidence.

“Their total is lower. Before we decide how to respond, can we compare whether migration, production monitoring, and the first thirty days of support are included in both?”

The purpose is not to make every proposal look equivalent. It is to stop an incomplete comparison from becoming a false price conclusion.

If the client asks you to produce a new number before these assumptions are clear, use the RANGE framework for on-the-spot estimates instead of turning the call into a guessing contest.

4. Connect the price to the decision and consequence

Do not recite your team's experience as a substitute for value.

“We use senior developers” matters only when you connect it to an outcome the client cares about: faster technical decisions, lower migration risk, fewer approval cycles, or ownership through production.

Use a simple sequence:

1. Restate the business outcome.
2. Name the proposal element that protects it.
3. Explain the consequence of removing that element.

“The launch date depends on migrating the existing customer data without stopping billing. The proposal includes a rehearsal migration and reconciliation report because that is the highest-risk part of the release. We can remove the rehearsal, but the saving comes with a less predictable production migration.”

This is not fear-based selling. The trade-off is real, specific, and available for the client to decide.

A weak defence sounds like:

“Our price reflects our quality and expertise.”

The statement may be true. It does not help the client evaluate the proposal.

5. Exchange something explicitly

If the price needs to change, something else usually changes with it.

You can exchange:

• Scope: remove or defer a workflow.
• Sequence: deliver a smaller first phase.
• Time: use a longer schedule or flexible start date.
• Terms: change payment timing without changing total price.
• Ownership: move a defined task to the client team.
• Risk: reduce testing or support only after making the consequence explicit.

Offer options that are operationally real:

“We have three workable paths. Keep the full scope at the proposed price. Move analytics and the admin workflow into phase two to meet the current budget. Or keep the scope and split payment across the two delivery milestones.”

Not:

“We can reduce the price, but we will try to keep everything.”

The second answer protects the deal on the call by transferring the cost into delivery.

When the client requests additional output without moving price or time, the same decision discipline applies as in our guide to pushing back on scope creep.

What a complete PRICE conversation sounds like

Client:

“We like the approach, but £42,000 is much more expensive than we expected. Another agency quoted £28,000.”

Founder:

“Understood. That is a meaningful difference. Before we change anything, can we compare whether both proposals include the existing-data migration, two payment integrations, and production support?”

Client:

“The other proposal includes the integrations. I do not think it includes migration; they assumed our team would handle that.”

Founder:

“That explains part of the gap. In our proposal, migration and reconciliation account for £8,000 because billing cannot stop during launch. We can move that responsibility to your data team, which brings us closer to the other figure, or we can keep ownership with us and phase the reporting module into the next milestone. Which constraint is firmer: the £30,000 budget or having one partner own the complete launch?”

The founder has not won an argument. They have made the real decision visible.

Prepare for the price conversation before sending the proposal

Know the floor and the trade space

Decide what cannot be discounted safely. Identify which workstreams can move, which terms can change, and who must approve an exception. Do not invent concessions while the client watches.

Make assumptions visible

Place important client responsibilities, exclusions, and estimate assumptions near the price—not in an appendix nobody will read. Ambiguity makes a cheaper proposal appear equivalent.

Give the client an internal explanation

Your champion may agree with the proposal and still fail to explain it to finance or a founder. Summarise the outcome, major cost drivers, risks covered, and available options in decision language.

Rehearse the uncomfortable version

Do not rehearse only a client who accepts. Practise with a client who has a lower quote, a fixed budget, delayed funding, or a belief that AI should make development nearly free.

What agency teams get wrong

The unexplained discount

A discount without a reason or exchange weakens the price and preserves every expectation.

The hourly-rate defence

The client did not ask for a payroll lecture. Explain the work, outcome, risk, and ownership represented by the total.

The cheaper-agency attack

Calling the alternative low-quality sounds insecure and may be false. Compare what is included and let the decision stand on evidence.

The feature avalanche

Adding more deliverables to justify the price increases cost and complexity. Clarify which outcome matters before expanding value.

The silent delivery compromise

The sales conversation ends with the original scope at a lower number, and delivery is expected to recover the margin. That is not negotiation. It is an undocumented change request against your own team.

Frequently asked questions

What should I say when a client says my software proposal is too expensive?

Acknowledge the gap, then ask whether the issue is budget, expected scope, comparison, perceived value, or approval. Compare assumptions before discussing a discount.

Should a software agency discount its proposal?

A discount can be appropriate, but it should have a clear commercial reason and approved boundary. If price changes, state whether scope, sequence, terms, ownership, or risk also changes.

How do I respond when another agency is cheaper?

Compare scope, assumptions, testing, migration, deployment, support, client responsibilities, and exclusions. Do not attack the competitor or claim superior quality without evidence.

What if the client's budget is genuinely fixed?

Offer a smaller first phase, defer lower-priority workflows, change payment timing, or move clearly defined responsibilities. Confirm the revised deliverables and consequences in writing.

How can a pre-sales team practise price objections?

Role-play several versions: fixed budget, cheaper competitor, weak value, delayed approval, and cash-flow concern. Practise diagnosing the gap before offering an option.

Knowing PRICE will not stop the discount reflex

The pressure arrives when the proposal matters, the pipeline is thin, and the client goes silent after naming the number.

PitchDawn lets agency founders and client-facing IT professionals practise negotiation, proposal, pre-sales, and difficult-client conversations with AI personas that push back in real time. The debrief helps reveal whether you became defensive, overexplained, discounted without a trade, or ended without a decision.

Explore practice modes for IT services and consulting on the PitchDawn industries page.

Start your first negotiation practice session free — no card required.