After 25 years of building bespoke software, the advice I wish I'd been given on day one is that saying no to a client isn't a failure - it's the highest form of service.
The Instinct to Say Yes
In a services company, the gravitational pull is always toward "yes". Yes to the new engagement, yes to the extra feature, yes to the deadline that doesn't quite add up. Saying yes feels like growth. Saying no feels like leaving money on the table.
Early in my career, I couldn't have imagined telling a paying client that their idea wasn't the right one, or that we weren't the right team, or that the feature they loved was the one holding their product back. Over the years I've learned that those conversations - uncomfortable as they can be - are where the real value of a long-term partner lives.
Here's what saying no looks like in practice, and what saying yes at the wrong time can cost.
No to the Wrong Engagement
We've turned down work a handful of times over the years. Sometimes the reason is straightforward - a personality mismatch that would make the working relationship difficult, or a domain so specialised that another team would serve the client better, in which case we'll plainly say as much, and offer guidance on finding a better fit for the project.
The harder task is saying no when you could take the work, but you know that you shouldn't. Growth is seductive, and it's a difficult prospect to reject - but sometimes a large engagement lands at just such a moment that you'd need to hire in order to deliver it. Too much rapid expansion without a consolidation period will surely lead to trouble; new hires need time to settle, some of them won't work out as you'd hoped, and the roles you originally hired for have evolved. Without taking time to stabilise, the majority of the strain will land on the senior team. Projects will start to feel chaotic, and your best people risk burning out as they leap between spinning plates trying to keep everything moving.
Saying no to that engagement protects all the engagements you're already running. It's not a comfortable call, but it's almost always the right one.
No to the Client's Solution (Not Their Problem)
The most common "no" in our work isn't actually a refusal, it's a redirection. A client comes to us with a solution already well formed in their head. Our job is to look past this solution to find the core problem, because in my experience, the two have often drifted apart.
On a healthcare project, our client was managing sensitive clinical processes and felt that the system needed to be overly rigorous to keep compliance tight; complicated rules governed what users could do and under which conditions. On paper, it made sense - the regulations were real. But in practice, the restrictions frustrated users so badly that they found workarounds in the software, generating good data that was incorrectly organised, which then poured back into the support queue as an endless stream of manual correction tickets.
We proposed relaxing the rigid rules in the next iteration - trusting in the training users had already received and shifting the system from restricting the user to guiding them. The client didn't come around to the idea, and the same problems persisted in the next version.
That's the uncomfortable truth about saying no: sometimes the client says no right back. The value is in making the case clearly enough that they're choosing with open eyes, not defaulting from lack of alternatives.
No to the Timeline (and the Feature List)
Scope creep can be the simplest reason for delivery failure. Each individual feature request is reasonable, adding a small load to the timeline, but collectively they add up fast - pushing the launch date further and further out.
The discipline we've learned is simple: if a feature is critical, then something else has to give. An on-time launch with a few missing nice-to-haves is far more strategic than waiting for one hundred percent completion and missing the starting gun.
A recent project of ours found an AI-backed summary feature generating real excitement among stakeholders, but the deadline for delivery was rapidly approaching. It would have been easy to hold the launch back until this new feature could be included, but we would have lost out on being first. Instead, we pushed the summary tool into phase two - giving the core product time to grow an audience first, and then landing the exciting new feature a few weeks later as a headline update. The result was two moments of positive attention instead of one delayed launch that may well have gone unnoticed.
No to the Feature They Love
Perhaps the most difficult conversation is telling a client that the feature they're most proud of is the one that's hurting their business.
On a recruitment platform we inherited, the client had invested heavily in a comprehensive applicant shortlisting tool. It was feature-rich, deeply configurable, and had been built with real care. It was also, according to their users, a headache. A wealth of options was making what could have been a sleek, focused experience feel sluggish and overwhelming. Users were drifting to simpler competitor tools.
We guided the client toward sunsetting the original feature and replacing it with a separate, streamlined microservice that did the core job well and nothing else. They weren't enthusiastic, but their users loved the simplicity of the new system.
What Happens When You Don't Say No
I'd be painting an incomplete picture if I only told stories where we got it right.
Earlier in our history, we took on a legacy rescue - a product that had been built offshore by what appeared to have been several distinct teams with severely limited internal communication. Documentation was non-existent, conventions were absent. The application was a monolith struggling to scale; response times were abysmal and data was being lost.
Eager for work, we said "yes" and spent the following weeks patching a seemingly endless series of holes. In our inexperience, we had vastly underestimated the scale of the problem. We ended up with a lot of frustration and a net financial loss.
In hindsight, the legacy product could have been used as a template for a completely new, API-decoupled suite of independent services - it would likely have taken the same time, but would have produced a far more maintainable result.
The lesson was an important one for us to learn: be careful how much you bite off. Not every engagement that looks like a good fit from the outside is one you should take at face value. Sometimes the right "no" is "not like this."
Earning the Right to Say No
For a client to listen when you say no, they first need to trust your expertise. Saying no from a position of earned authority is advice. Saying no without it is just obstruction.
This trust is built over years of putting in the work, delivering what you said you'd deliver, and being honest when the path forward isn't the one the client expected. Most of our long-running partnerships grew specifically because we were willing to have the difficult conversation early, rather than the expensive conversation later.
The most valuable service a software partner can provide isn't always building exactly what the client is asking for.
Sometimes it's having the courage to explain why we shouldn't.
See the original post on Matt's website: tiltedsky.net(opens in new tab)