The Objections You Get, and What They Actually Mean

Objections are usually treated as obstacles to overcome, which is both unpleasant and ineffective. They are better understood as information: a client raising a concern is telling you what is unresolved for them, and the useful response is to find out what is actually being asked rather than to deploy a rehearsed answer.

The recurring ones are remarkably consistent across projects and industries, and almost all of them are proxies. "It is too expensive" is usually about risk. "Can you start sooner" is usually about a deadline nobody has explained. Answering the surface question leaves the real one untouched, which is why an objection that seems resolved often reappears a week later.

This post covers the eight I hear most, what is generally underneath each, and how to answer in a way that is honest rather than persuasive — including the cases where the correct answer is that the objection is right.

Why treat objections as information?#

Because a client who raises one is engaged, and a client who does not is often gone.

Silence after a proposal is the outcome to worry about. An objection means somebody has read it, taken it seriously, and identified the thing preventing a yes. That is a gift, and treating it as an argument to win wastes it.

It also changes what a good response looks like. If the goal is understanding rather than conversion, the first move is always a question, and the question is nearly always some version of what specifically is causing the concern. That single habit resolves more objections than any script.

Every row on the right is answerable and every row on the left is not, which is why answering the stated version so often fails.

Ask before answering, every time#

"Can I ask what you were expecting?" or "what is driving that?" costs one sentence and reframes the conversation from defence to diagnosis. It also signals that you are interested in their situation rather than in closing, which is more persuasive than anything you could argue.

"It is too expensive"#

Almost always about risk rather than the number.

Very few clients have a precise sense of what development should cost, so "expensive" usually means "this feels like a lot to commit to something I am not certain about". The concern is not the figure — it is the possibility of paying it and not getting what they need.

Reduce the risk before reducing the price#

A smaller first engagement that produces something real is a better answer than a discount. A one-to-two week fixed-scope piece that delivers a working component lets them evaluate you at a fraction of the exposure, and most of those become larger projects.

Show what is in the number#

Clients frequently imagine they are paying for code and are surprised by the rest — environment setup, testing, review cycles, deployment, documentation, handover. Making the composition visible converts an opaque figure into an itemised one, and opaque figures feel expensive by default.

Offer less scope, never a lower price#

Dropping the price for the same deliverable tells them the original number was arbitrary and invites further negotiation. Offering a reduced scope at a lower figure keeps the rate intact and often reveals that a third of the scope was optional anyway.

Sometimes it is genuinely too expensive#

If their budget is a quarter of what the work costs, that is not an objection to handle — it is a mismatch. Saying so directly, and suggesting what could be done within their budget or who might suit them better, is more useful than a negotiation neither side can win.

"Why does it take that long?"#

Usually a genuine gap in understanding rather than scepticism.

From outside, software looks like typing, and estimates that include review cycles, testing and deployment appear padded. The client is not accusing you of inefficiency — they are missing information about what the work contains, and that is straightforward to supply.

Break the timeline into visible pieces#

Showing the phases and roughly what happens in each turns an unexplained duration into a sequence somebody can follow. It also gives them a place to push back meaningfully, which is a better conversation than arguing about a total.

Name the parts that are not building#

Review cycles depend on their availability. Deployment and testing take real time. The operational baseline — staging, monitoring, backups — is a day that pays for itself the first time something breaks. Naming these makes the timeline legible.

Offer the fast version honestly#

There is usually a shorter path with real trade-offs — fewer tests, less polish, deferred edge cases. Presenting that as a genuine option with its costs stated respects their judgement, and clients frequently choose the longer version once they can see what the shorter one omits.

"Can we use a different technology?"#

Find out whether it is a constraint or a preference, because they need opposite responses.

A constraint deserves compliance or a referral#

An in-house team, an existing codebase, a corporate standard or a compliance requirement is real. Work within it or decline — arguing against a genuine constraint is a poor use of the relationship and it rarely works.

A preference deserves a question#

When it comes from an article or a colleague's enthusiasm, asking what problem they hope it solves is the right move. Often the underlying concern — performance, hiring, longevity — can be addressed within your stack, and the specific technology stops mattering once the worry is named.

Be straight about your own capability#

If you do not know their preferred stack well, saying so is better than learning at their expense. A referral costs you a project and builds more credibility than a mediocre delivery would, and referrals tend to come back.

Price the unfamiliarity if you take it#

Working outside your defaults is slower and riskier, and that belongs in the estimate rather than being absorbed. Stated plainly, this is an uncontroversial conversation — and it is why having defaults matters.

"Can you do it for a fixed price?"#

Usually a request for certainty, and often reasonable.

Behind this is nearly always a previous experience of an open-ended engagement that ran over. The client is not trying to transfer risk maliciously; they are trying to bound an outcome they have been burned by before, and that is a legitimate thing to want.

Fix what is understood, not what is not#

Well-defined work with a clear boundary can be fixed confidently. Work depending on an undocumented legacy system cannot, and fixing a price on it means either padding heavily or accepting an overrun you will resent.

Phase it instead of refusing#

A fixed-price discovery phase that produces a fixed price for the build gives them the certainty they want without asking you to guarantee something unknowable. It is a genuinely good answer and it is available more often than people use it.

State what changes the price#

A fixed price with written assumptions is fixed conditionally, and saying so up front is what makes it fair. The conversation to avoid is discovering in week four that an assumption was wrong and having nothing written down about it.

"We might build it in-house"#

Frequently a real option and sometimes a negotiating position — and the distinction matters less than you would think.

Either way, the useful response is the same: help them evaluate it honestly. A client who reaches the conclusion themselves is more committed than one who was argued out of it, and if in-house genuinely is better, you did not want that project anyway.

Name the real comparison#

The comparison is not your fee against a salary. It is your fee against hiring time, onboarding, the opportunity cost of the team's existing work, and the fact that a first project on an unfamiliar stack takes longer. Laying that out neutrally is more persuasive than advocacy.

Offer to complement rather than replace#

Building the foundation and handing it to their team, or working alongside them, is often the actual best answer and it is one they may not have considered. It also produces a relationship rather than a transaction.

Accept it gracefully when it is right#

Some things genuinely should be built in-house — anything core to the business that will need continuous evolution. Saying so costs a project and it is the advice that gets you recommended, which is worth more over time.

"Send me more detail"#

Sometimes a genuine request, often a way of not deciding.

The tell is whether the request is specific. "Can you clarify how the migration would work" is a real question. "Send over some more information" with no specifics usually means either they are not the decision-maker or something unstated is blocking it.

Ask what would make the decision easy#

A direct question — "what would you need to see to move forward?" — either produces a real answer or reveals that the decision is not theirs. Both are useful, and both save you from writing a document nobody reads.

Do not write a proposal you were not asked for#

Responding to vagueness with volume is a common and expensive habit. A long document produced speculatively is unpaid work with a low conversion rate, and it rarely addresses whatever the actual blocker was.

Find the decision-maker politely#

"Is there anyone else who should be part of this conversation?" is a normal question and it saves weeks. A proposal that never reaches the person who decides cannot succeed regardless of how good it is.

"Can you start sooner?"#

There is a deadline, and it is worth understanding before agreeing to anything.

Urgency always has a source. A contract, a funding milestone, an event, a competitor — or sometimes nothing beyond impatience. The source determines whether the timeline is a genuine constraint worth reorganising around, and it is a single question away.

Ask what happens on that date#

The answer tells you how real it is and often reveals that a partial delivery would satisfy it. A launch that needs one flow working by a date is a very different project from one needing everything, and clients frequently have not made that distinction themselves.

Do not agree to a timeline you do not believe#

Accepting an unrealistic date to win the work guarantees a difficult project and a bad outcome for both parties. Saying what is achievable, and what would need to be cut to hit their date, is the honest version of the same conversation.

Offer a phased delivery#

Something working by their date and the rest afterwards is often exactly what they need and rarely what they asked for. Proposing it demonstrates that you engaged with the constraint rather than the request.

"We need to think about it"#

Something specific is unresolved, and it is worth finding out what before the conversation ends.

This is rarely a considered pause — usually there is a particular concern that has not been said aloud, and once the meeting ends the chance to address it goes with it. A single direct question at that moment is worth more than any follow-up email.

Ask what the hesitation is#

"Is there anything in particular giving you pause?" is unpushy and frequently produces the real objection, which is often something small you can resolve in a sentence. People will usually tell you if asked directly and gently.

Agree a next step, not a follow-up#

"I will check in next week" puts the burden on you and invites a slow fade. "Shall we speak on Thursday once you have discussed it internally?" produces a decision point, and their willingness to agree one is itself informative.

Let some go#

Not every conversation should convert, and chasing one that has gone quiet costs time and standing. A polite close that leaves the door open is better than three follow-ups, and clients do come back — and some projects should be declined anyway.

What about objections during the project?#

Different in character — these are about expectations rather than about buying.

"This is not what I expected"#

Usually a scoping failure surfacing late, and the response is to establish exactly where the divergence is rather than to defend the work. Sometimes it is a genuine miss on your part, and saying so quickly costs far less than defending it.

"Can we just add..."#

Normal, healthy, and requiring a process rather than a judgement. Every addition gets a quick estimate and an explicit decision, presented as a trade — added to the timeline or swapped for something else — so it is a choice rather than an argument.

"Why is this taking longer?"#

Usually because something was harder than estimated, and the honest answer is that. Explaining the specific reason, what it means for the date, and what the options are is more reassuring than reassurance, and it protects the relationship for the next estimate.

What is the underlying skill?#

Being willing to lose the project, which is what makes honesty possible.

Every technique here depends on it. If you need this particular project, you will agree to the timeline you do not believe, accept the fixed price on unknowable work, and answer the stated objection rather than the real one. The pressure is visible to the client and it makes everything less convincing.

A pipeline is what buys the freedom#

The practical foundation for saying no is having enough other conversations that any single one is not decisive. That is a business development problem rather than a communication one, and it is the actual root of most difficulty in this area.

Honesty converts better anyway#

Telling somebody their deadline is unrealistic, or that their budget does not match the scope, or that they should build it in-house, is more persuasive than the alternative — because almost nobody does it and it signals that your other statements are reliable too.

What does it cost?#

Some projects, and the discomfort of asking direct questions.

Handling objections honestly means losing work you could have won by being agreeable — the unrealistic deadline you declined, the fixed price you would not quote, the in-house option you validated. Those are real losses and they are mostly projects that would have gone badly.

The honest counterweight: this approach assumes a market where you can afford to be selective, and that is not everybody's situation. Somebody starting out, or in a thin period, has to take work that a more established practice would decline, and there is nothing shameful in that — the advice to walk away from a bad-fit project is much easier to give than to follow when the pipeline is empty. The realistic version is to be as honest as you can afford to be, and to treat building the pipeline as the thing that makes the rest of it possible.

An objection is a client telling you what is unresolved. Treating it as an argument to win wastes the most useful thing they have said.

Conclusion#

Objections are information rather than obstacles, and a client who raises one is engaged — silence after a proposal is the outcome to worry about. Almost all of them are proxies, so the first move is always a question about what specifically is causing the concern.

"Too expensive" is usually about risk, answered with a smaller first engagement rather than a discount. "Why so long" is usually a genuine gap in understanding, answered by making the phases and the non-building work visible. "Can we use X" needs separating into a constraint, which deserves compliance or a referral, and a preference, which deserves a question.

A fixed-price request is a request for certainty from somebody previously burned — fix what is understood, phase what is not, and state in writing what changes the number. An in-house option deserves an honest comparison rather than advocacy, because a client who reaches the conclusion themselves is more committed either way.

Treat an unspecific request for more detail as a signal that the decision sits elsewhere, ask what happens on the date behind any urgency, and when somebody needs to think about it, ask directly what is giving them pause before the conversation ends.

Mid-project, the same principle applies to different content: expectation gaps rather than buying concerns, handled with a change process rather than a debate. All of it rests on being willing to lose the project, which is a pipeline problem before it is a communication one — and honesty converts better anyway, because almost nobody offers it. If that is the sort of conversation you want to have, start here.