There’s a sentence that, in consulting—at least where I work—sounds almost like blasphemy. One of those things you think while you watch yet another meeting turn into a catalogue of requests, but then you don’t say. Because it’s not done, because of “the client relationship”, because the salesperson glares at you and someone reminds you that “we’re here to satisfy needs”.
And yet.
The customer is wrong.
Not always, of course. Not on everything. But much more often than we like to admit. And I wonder whether the real problem isn’t the customer themselves, but the polite lie we’ve been telling them for years. The one about “the customer is always right”. A lie that, in Italian software, has done damage you can’t even properly count, because failures rarely come with a sign saying “failure”. Usually they’re quieter. They’re projects that go to production and then no one uses. Money burned on things that don’t improve anything. Long nights of people who knew it was going wrong but didn’t have the space, or the permission, to say so.
This is a slightly mean piece. I’m not asking you to agree. I’m only asking you to be honest, at least for the duration of this read.
The yes that kills projects
I’ve watched more projects die from a yes than from a no.
The mechanism is almost always the same, and that’s exactly why it’s frightening. The client asks for something. You know it, you feel it, you see it in the details: it’s wrong technically, or economically, or just as a direction. But you say yes anyway.
You say yes because there’s a contract. Because there’s a relationship to protect. Because “we’ll fix it later”. Because the handshake already happened and going back feels like defeat. Because saying no is uncomfortable, requires arguments, requires energy, and above all requires courage.
So the project doesn’t die in one go. It dies one yes at a time.
Every yes adds a feature no one will use. Every yes shifts a piece of the deadline, or compresses a piece of the quality. Every yes makes the architecture a little more fragile and the code a little more contorted, until what you’re building no longer looks like a product, but a layered compromise.
In the end you ship software that does a hundred and fifty things, none of them well, and the client looks at you and says: “this isn’t what I wanted”.
And here’s the part that stings, because in a sense they’re right. It isn’t what they wanted. It’s what they asked for. Two different things.
And maybe our craft, the real one, isn’t to execute orders. It’s to recognise the difference.
Catalogue of horrors (all real, sadly)
What follows is true. The names are changed, the dynamics aren’t. And if you find yourself thinking “I’ve seen one just like that”—you aren’t alone.
The endless management system
A medium-large company asks for a management system. So far, normal. Then, while it’s being built, every department adds requirements. HR wants the leave module, marketing wants the dashboard, accounting wants the integration with the bookkeeper, and each one is convinced they’re the centre of the world.
No one has the power to say enough, because every department is an “internal client” who “is right”. Result: eighteen months of development, a product that does everything badly, and after release the company keeps using Excel. Which, in the end, at least doesn’t betray you.
The carbon-copy tender
A municipality has to digitalise a service. The tender is written by copying one from another municipality—maybe three times bigger, with completely different needs. Inside it end up requirements that read well on paper but no citizen will ever use.
Whoever wins the contract often knows. But the tender is the tender. So you build exactly what’s written. You deliver, you test, you tick boxes. The platform goes live.
Six months later the service is still being handled by phone.
And the saddest part is that, formally, everything went fine.
The app that was supposed to change everything
A local public administration wants a mobile app for citizens. The decision-maker is a council member who saw another municipality’s app and wants the same one. No needs analysis, no user research, nothing. Just: “I want the app”.
The vendor builds it. At launch, four hundred people download it. After three months it’s used by twelve, counting council employees.
The council member holds the press conference and talks about innovation. The vendor cashes the cheque and moves on to the next.
And I can never decide who in this story makes me more uncomfortable.
The restyle that was a rewrite
A client asks to “freshen up” the website. The salesperson sells a restyle. At the first operational meeting it emerges that the site has no CMS, the database is an Excel sheet, content doesn’t exist, and “freshen up” means rethinking the entire digital presence.
But the quote is for a restyle, the timeline is for a restyle, and the expectations are for a restyle.
Everyone knows it isn’t a restyle. No one says so.
The zombie project
A project was supposed to last six months and is in its third year. It doesn’t work, isn’t being used, but no one closes it because closing it would mean admitting it was a mistake.
The client keeps paying for change requests. The vendor keeps invoicing. Both know it’s dead. Both pretend it’s alive.
It never officially fails. It just stops being mentioned in meetings, like an awkward uncle no one talks about at lunch.
Why it actually happens
It happens because our sector has a structural problem with truth.
The business model of Italian IT consulting is built on yes. You win projects by saying yes. You retain clients by saying yes. You get promoted by saying yes. The whole system, from sales to project managers to developers, is optimised to minimise conflict and maximise short-term invoicing.
The trouble is, short-term and long-term are at war.
Saying yes today almost always means paying tomorrow. Every extra feature is technical debt. Every requirement accepted without analysis is a time bomb. Every timeline compressed to please someone is a guarantee of overtime—often unpaid—and of sacrificed quality.
Meanwhile the client never learns. Not because they’re stupid, but because no one tells them that request was wrong. No one tells them that tender was poorly written. No one tells them that app was useless to anybody.
Surrounded by people who nod, the client keeps asking for the same wrong things, and the cycle starts again.
And here’s the part that hurts, because it shifts the responsibility.
It isn’t the client’s fault. It’s ours.
It’s the fault of a sector that gave up its role—the role of the expert. The one who knows things the client doesn’t, and who has the duty, not the right, to say them.
The no as service
The best service you can give a client is to say no.
No, that feature isn’t needed.
No, that timeline isn’t realistic.
No, that tender is poorly written and if we follow it to the letter we’ll build something useless.
No, you don’t need an app.
No, you don’t need AI.
No, you don’t need a restyle. You need to stop and figure out what you actually want to do.
Every no costs. It costs awkwardness, costs tension, costs a few hard phone calls. Sometimes it costs the project.
But every no is also an act of respect for the client, because it treats them as an adult who can hear the truth, not as someone to be placated for a quiet life.
The best clients I’ve had in my career are the ones I’ve said the most “no” to. At first they tense up, which is normal. Then, if you hold firm and you argue calmly, something happens: they understand that when you say yes, you can be believed.
Trust isn’t built on continuous agreement. It’s built on candour.
And candour, in our sector, is rare. Maybe rarer than a good developer. Maybe rarer than a project delivered on time. Maybe rarer than a well-written tender.
A minimal manifesto, no heroics
I don’t know if this is a manifesto, but if it is, for me it lives in three lines.
Don’t say yes when you know it’s no.
Don’t build what the client asks for if you know it isn’t what they need.
And when you’re wrong—because you will be wrong, and we all will—at least be wrong by telling the truth, not by nodding.
The customer isn’t always right. But they always deserve someone with the courage to tell them.
Key takeaways
Every yes adds technical debt, compresses quality, and sets up the final “this isn’t what I wanted”.
Trust isn’t built on continuous agreement but on candour: when you say yes, they can believe you.
Candour, in our sector, is rarer than a good developer or a well-written tender.
Questions & answers
Why does always saying yes to the client kill consulting projects?
Because clients often phrase a solution when they should phrase a problem. Saying yes to “I want a mobile app” when the real problem is “my sales reps lose time on field reports” means building a correct thing for the wrong problem. The automatic yes ships the project that was asked for, not the one that was needed—and six months later it’s the consultant who looks bad, not the brief that was weak.
How do you say no constructively?
Separate the parts. “No to this solution, yes to the underlying problem, let’s look at alternatives together.” The client doesn’t want to hear only “no”—they want to know you understood what they need and that you’re protecting their investment from their own first instinct. “No” alone is arrogant; “no + here’s why + here’s what I propose” is service.
Isn't saying no risky in a competitive market?
Risky in the short term, the opposite in the medium. Serious clients remember who saved them from a bad decision—and they come back. Clients who only want yes-executors are often the worst to work with, because the project ends badly and they offload responsibility. Filtering with an early no is often the most effective way to earn the right clients.
Where does no become problematic?
When it becomes identity rather than service. A consultant who says “no” to everything to differentiate themselves is as useless as one who says “yes” to everything. The discipline is to say yes when the client is right, no when they aren’t, and to be able to explain the difference in terms they can evaluate. It takes more competence, more time, more respect—all things that go missing when you scale on the T&M model.