The Vendor Who Says No — Why Discouraging a Project Is Sometimes the Best Service
You’re collecting proposals for a major IT project. The first vendor says they’ll build everything on your requirements list. The second promises a team starting Monday. The third asks why you need half those features and suggests starting with something smaller. The natural reaction is to go with the first two. After all, you want a partner who wants the project.
But the most expensive mistake in IT rarely sounds like “we chose the wrong technology.” It more often sounds like “we signed a contract for something that never made sense from day one” — and we found out after spending the first few hundred thousand. A vendor who says “no” or “not in this form” doesn’t necessarily lose the deal. Sometimes they do the best work they can do before any contract is signed.
In brief
|
Why the market rewards yes, not honesty
A vendor earns money by signing a contract, not by whether the investment pays off.
In a time-and-materials model, every month of development is an invoice. The bigger the scope at the start, the longer the contract. A vendor who says “half of this isn’t needed” is cutting their own revenue. A vendor who says “let’s first check whether you need a custom system at all” risks the project never starting.
The pressure on your side is similar. The board wants dates. Investors ask about the roadmap. Sales promised features to customers. In that atmosphere, an offer that says yes sounds like solving the problem. An offer that says no sounds like another obstacle.
The problem is that only 48% of digital initiatives deliver their intended business outcome — according to a Gartner survey of more than four thousand IT and business leaders. Half of projects don’t deliver what they were supposed to, often because nobody stopped at the beginning to ask: does this even make sense at this scale and in this form?
“No” has several meanings — and rarely means rejecting the whole idea
When a good vendor says no, they usually specify what the refusal is about.
That distinction matters. A CEO who hears a refusal often assumes: “they don’t want our money.” In practice, refusal looks different:
- Not this scope. “We won’t build everything at once. Yes — let’s start with the module that solves one specific problem.”
- Not now. “Let’s not start development until you’ve defined a success metric.”
- Not custom software. “Your problem can be solved with an existing tool or an integration. A dedicated system will cost more than the benefit.”
- Not this collaboration model. “At this level of uncertainty, fixed price doesn’t hold up. You need a discovery phase before we lock scope.”
Each of these refusals can still lead to a partnership — just in a healthier form. A vendor who rejects the entire project without explanation and without an alternative does the same thing as one who says yes to everything: they leave you with a decision you don’t understand.
Four situations where discouraging a project protects your budget
The biggest savings in IT are sometimes avoiding an investment that never had a chance to pay off.
Below are four patterns from real sales conversations. We omit company names and industry details — the mechanism is the same regardless of sector.
Many automation ideas, not one problem to solve
A company came with a list of automation ideas: several different processes that “would be worth improving.” Each one sounded reasonable on its own. Together they formed a scope of many months of work and hundreds of thousands — without a single number showing whether the whole thing would pay off.
After verification, we proposed something other than “we’ll do everything on the list.” We pointed to the automations that, in our view, had a chance to pay off commercially — and we delivered those. The rest we rejected or deferred.
In parallel, we recommended replacing the company’s core management system with a more advanced one. Half the features the client had asked about in the context of custom development were already built in. Instead of building from scratch, it was enough to implement a tool the company needed anyway at a higher level of maturity.
The refusal didn’t sound like “we don’t want your project.” It sounded like: “don’t build custom software for things you already have in an off-the-shelf system — and don’t automate everything at once, only what makes economic sense.” The client got a shorter path to results and a smaller bill than with the full list of ideas.
Automation “to free up two people”
Another company came with a clear goal: a five-person back-office team, two of whom were to move to other tasks. The idea: automate their work so the rest of the team could manage without them.
We did not recommend that project.
Automation makes sense with highly repetitive work — the kind where the same pattern repeats hundreds of times a month and can be described with rules. When the main goal is to “replace people with AI” or custom software, and you’re talking about two people in a small team, the math usually doesn’t add up. The cost of building, implementing, and maintaining the system exceeds the savings on salaries — especially if the process isn’t fully repeatable and requires exceptions that automation can’t handle.
The exception starts at larger scale: more than five people on one simple process. Then the calculation can work. With two people in a five-person department — rarely.
A vendor who said “yes, we’ll build a platform” would earn on the contract. A vendor who said “no, this won’t pay off” saved the client a project that looked modern but had no chance of return.
No business owner and no measurable goal
A mid-sized manufacturing company wanted “a system that would improve operations.” At the meeting were five people with five different definitions of “improvement.” Someone talked about reports. Someone about ERP integration. Someone about an app for field technicians. Nobody could answer: what one business number should this project improve within six months?
The refusal was: “We’re not starting development until you assign one person on the business side who owns priorities, and one metric by which you’ll judge whether the project succeeded.”
That wasn’t a minor formality. Without it, the development team builds features nobody will measure. A quarter later you’ll hear “we delivered module X,” but you won’t be able to say whether operations ship faster or the cost per order dropped. We write more about connecting company strategy with IT projects in our article on business strategy and IT projects.
The numbers don’t add up — even when the idea sounds modern
The goal “free two people through automation” is one example. The same pattern shows up in other forms: an AI platform, a custom reporting module, an integration “because competitors already have it.” Technically, all of it can be built. The question is whether the cost of building, implementing, and maintaining it pays back within a horizon you accept.
If the vendor doesn’t ask that question at the start, you’ll hear the answer only after you’ve spent the budget. In a time-and-materials model, you carry the economic risk. A vendor who refuses even though they could have signed the contract is doing an advisor’s job — not a salesperson’s.
How to spot a vendor who will tell the truth
Look for someone who asks uncomfortable questions before proposing a team.
A few signals worth checking before signing:
- They ask “why” before “how.” Before you hear about technology and headcount, a good vendor wants to understand the business problem and the success metric.
- They refuse items on your requirements list. If everything you put in the brief lands in scope without discussion, they either don’t understand the context or never plan to say no.
- They propose a smaller step instead of a large contract. A discovery workshop before development or a proof of concept on one module isn’t delaying the project. It’s a way to test assumptions before you spend six figures.
- They speak plainly about risks. Not “everything can be done,” but “at this scope and budget we risk X — here’s what we propose instead.”
- They’re not afraid to lose the deal. A vendor who prefers truth to signing a bad deal thinks long term. Even if you don’t sign a full-project contract now.
That doesn’t mean you should look for a vendor who refuses everything. It means yes should be justified, not automatic.
What to do when you hear “no”
A CEO’s first reaction is understandable: if this one doesn’t want it, I’ll find someone who does. Sometimes that makes sense — for example when the refusal comes from lack of industry expertise, not from a real analysis. More often, looking for a vendor who will say yes at any cost ends exactly where the first vendor was trying to protect you.
Ask three questions:
- What does the refusal cover? The whole project, scope, timing, technology — or the collaboration model?
- What does the vendor propose instead? If they refuse without an alternative, it’s a weak refusal. If they say “not like that, but yes in another form” — you have material for a conversation.
- Does my side meet the conditions they listed? Sometimes “no” means: first sort out internal decisions, assign an owner, calculate ROI — and come back.
If two independent vendors say the same thing, it’s no longer one company’s quirk. It’s a signal to slow down before you sign.
What to do next depends on what you heard
- If the refusal was about too much scope at the start, see how feature creep quietly eats your budget — and how to stop it before you launch with a full requirements list.
- If you want to compare offers and know what to demand before signing, start with cost transparency in a software project — the second article in the “before you sign” series.
- If you were missing a business goal and success metric, go back to fundamentals: business strategy and IT projects.
- If the vendor proposed a smaller step instead of a full contract, see what a discovery phase offers within custom software development — before you spend serious money on development.
Summary
A vendor who says no isn’t a vendor who doesn’t want to work. Often they’re a vendor who understands that their real job starts with an honest assessment of whether the investment makes sense — not with signing a contract for everything that fits the budget.
Most of the market rewards yes. Your job isn’t to find someone who says yes fastest. It’s to find someone who tells the truth before you spend money you won’t get back just because the system “works.”
Sometimes the best service a vendor can offer is discouraging a project that should never have started in the form you planned. The rest is negotiation detail.
Before you sign – do you know what to expect from your vendor?
The Product Health Checklist covers 25 questions across five areas: strategy, discovery, delivery, collaboration, and ownership. Work through it before your vendor conversations — and enter negotiations with standards, not a wish list.
