Good engineering partners push back early.
Sometimes the requested feature is solving the wrong problem. Sometimes the simpler version is more useful. Sometimes the business needs an operational fix before it needs software.
Saying that clearly is part of the work.
It is also the part most vendors quietly skip, for reasons that are entirely rational and entirely bad for the client.
Why Vendors Do Not Push Back
Nobody decides to build the wrong thing. The incentives just make it easier not to ask.
A vendor paid to deliver a specification has three good reasons to deliver the specification:
- Disagreement is expensive. It costs a difficult conversation with the person who wrote the spec, who may have spent political capital getting it approved.
- Building is safer than advising. If you build what was asked and it fails, that is the client’s strategy. If you talk them out of it and the alternative fails, that is your judgment.
- Scope is revenue. The feature you argue against is the feature you do not get paid to build.
None of this requires bad faith. It is what happens when the contract rewards output and nobody is accountable for whether the output mattered.
The result is a well-executed system that solves a problem the business did not have. Everyone did their job. The money was wasted anyway.
The Four Kinds Of Wrong
Pushback is only useful if it is specific. “I do not think this is a good idea” is not feedback. In practice, the requests we challenge fall into four recognisable shapes.
The wrong layer. The request is software, but the problem is process. A client asks for a dashboard to track how often a handoff fails. The handoff fails because two teams have contradictory targets. A dashboard will measure the dysfunction very precisely and change nothing.
The wrong scale. The request assumes a volume, complexity, or user count that does not exist yet. Multi-tenant architecture for a product with four customers. A workflow engine for a process that runs eleven times a month. The cost is not just the build — it is every future change moving through machinery sized for a company you are not yet.
The wrong symptom. The request addresses the thing that hurts rather than the thing causing it. “Users keep entering bad data, so add validation.” Often correct. Sometimes the real answer is that the form asks for information the user does not have at that moment, and no amount of validation fixes that.
The wrong sequence. The request is right but premature. It depends on data you are not yet collecting, a behaviour users have not adopted, or a decision the business has not made. Building it now means building it twice.
flowchart TD
A[Feature request] --> B{Does it address<br/>the actual cause?}
B -->|No| C[Wrong symptom]
B -->|Yes| D{Right layer —<br/>software vs process?}
D -->|Process| E[Wrong layer]
D -->|Software| F{Sized for reality<br/>or for ambition?}
F -->|Ambition| G[Wrong scale]
F -->|Reality| H{Dependencies<br/>in place?}
H -->|No| I[Wrong sequence]
H -->|Yes| J[Build it]How We Actually Do It
The method matters more than the instinct. Done badly, pushback reads as obstruction.
Ask about the outcome, not the feature. The first question is never “why do you want this?” — which sounds like a challenge. It is “what will be different once this exists?” That question is easy to answer and it surfaces the underlying goal without anyone defending a position.
Separate the goal from the mechanism. Nearly always, the client is right about the goal and we are debating the mechanism. Making that explicit lowers the temperature immediately. We agree the renewal process is losing deals. I am not sure a notification system is what fixes it.
Bring an alternative. Objection without a proposal is just friction. If we think the feature is wrong, we owe a specific description of what we would do instead, what it costs, and why we think it gets further.
Be concrete about the cost of being wrong. Not “this might be over-engineered” but “this adds roughly three weeks now and makes every subsequent change to the billing flow slower, because it puts a queue between two things that currently talk directly.”
Say it once, clearly, then defer. This is the discipline that makes the rest sustainable. We state the concern plainly, make sure it was understood rather than merely heard, and then — if the client still wants it — we build it properly and without sulking.
The Client Is Often Right
This is the part that keeps pushback honest.
We are the experts on building software. The client is the expert on their business, their customers, their regulator, their board, and the political reality of their organisation. A request that looks irrational from the outside is frequently a rational response to a constraint we cannot see.
We have argued against features and been wrong. A “redundant” report that turned out to be the artefact a regulator asks for. An “over-engineered” permission model that anticipated an acquisition we had not been told about. A “premature” integration that was the condition of a partnership deal.
The correct posture is confidence about engineering consequences and humility about business context. We can say with authority what a decision will cost to build and maintain. We cannot say with authority whether that cost is worth paying.
So we push back once, we listen properly to the answer, and we update. If the client says “I hear you, and there is a reason I cannot fully explain” — that is a complete answer, and we get on with it.
Why It Is Free
We do not bill for the conversation where we argue against work.
Partly this is practical: charging to talk you out of something is a strange product. Mostly it is about removing the last incentive to stay quiet. If pushback were billable, every objection would carry a suspicion of self-interest.
It also changes what clients bring us. When the scoping conversation is free and genuinely two-directional, people arrive earlier — with a problem rather than a specification. That is the point at which advice is worth the most and costs the least.
The economics work out. A client who trusts our judgment on what not to build is a client who keeps calling. The alternative — a well-executed system that nobody uses — buys one invoice and no reputation.
What This Sounds Like In Practice
A few things we have said, more or less verbatim:
- “You can have this in three weeks. But I think in six months you will have deleted it, and I would rather spend the three weeks on the thing underneath it.”
- “This is a hiring problem wearing a software costume.”
- “We can build this. It will work. I do not think anyone will use it, and here is why.”
- “The simplest version of this is a shared spreadsheet and a weekly meeting. Try that for a month. If it holds, we will build the real thing and we will know exactly what it needs to do.”
That last one has cost us more revenue than any other sentence we say. It has also produced better second engagements than any proposal we have written.
The Bottom Line
The most valuable thing an engineering partner can do is occasionally refuse to build something.
That only works if the pushback is specific, comes with an alternative, is stated once rather than relitigated, and is followed by genuine deference when the client knows something you do not.
We do not charge for it, because the moment it becomes billable it stops being trustworthy.
If a vendor has never told you that a feature is wrong, it is worth asking whether they have been paying attention — or simply been paid not to.