We don't talk about this much in our industry. When projects go wrong, the standard response is silence. Pretend it didn't happen. Move on.
But we believe in transparency. So here's a story about a client relationship we ended — why we did it, what we learned, and how it shaped who we work with today.
Names and details are changed to protect privacy, but the lessons are real.
The engagement that wasn't
We'll call them Greenfield Industries. They came to us with an ambitious project: a complete digital transformation of their operations. Legacy systems replaced. Processes automated. Data unified.
On paper, it was exactly the kind of work we love. A meaningful challenge. A clear opportunity for impact. A client who said all the right things about partnership and long-term thinking.
We signed a statement of work. We kicked off discovery. Everything looked promising.
Then reality set in.
The warning signs
Looking back, the warning signs were there from week one. We just didn't want to see them.
Scope that never stopped growing
Every meeting added new requirements. "While we're at it, can we also..." became a refrain. The project that was scoped at 600 hours had grown to 1,200 hours before development even started.
When we raised this, the response was always the same: "We'll figure it out. Just get started."
What we should have done: Stopped. Insisted on a revised scope before proceeding. Made clear that scope changes require timeline and budget changes.
What we did: Accommodated. Tried to be flexible. Told ourselves it would stabilize.
Communication that went one way
We provided regular updates. Detailed status reports. Clear questions that needed answers. The responses were sporadic at best.
Decisions that should have taken a day took two weeks. Questions sent to the project sponsor disappeared into a void. Meeting requests were routinely declined or rescheduled.
What we should have done: Escalated earlier. Made the communication breakdown a formal issue.
What we did: Worked around it. Made assumptions. Tried to keep moving.
Blame that always pointed outward
When problems arose — and problems always arise — the response was never "how do we solve this together?" It was "whose fault is this?"
Our team was called out in front of their executives for issues that stemmed from their delayed decisions. Missed deadlines caused by their scope changes were attributed to our "poor planning."
What we should have done: Documented everything from the start. Established clear accountability.
What we did: Took more responsibility than we should have. Tried to maintain the relationship.
Moving goalposts
The definition of success kept changing. Features we delivered to spec were suddenly "not what we meant." Requirements we confirmed in writing were disavowed in meetings. The target we were aiming at kept moving.
What we should have done: Held firm to documented requirements. Required sign-off before proceeding.
What we did: Adapted. Revised. Rebuilt.
By month three, we had rebuilt the same module four times. Not because we'd built it wrong — because the requirements changed after each delivery. We were running in place.
The turning point
The moment of clarity came in a project review meeting.
We presented the status: two months behind schedule (due to scope changes), over budget (due to scope changes), and with several modules still in flux (due to, you guessed it, scope changes).
The client's response: "This is completely unacceptable. You clearly don't understand our business. We need to talk about how you're going to fix this without charging us more."
In that moment, something shifted.
We had been bending over backward to make this work. We had absorbed scope changes. We had worked weekends. We had taken responsibility for problems we didn't create. And the result was being blamed for the chaos we'd been trying to manage.
This wasn't a partnership. It was a one-sided relationship where we provided value and absorbed blame.
The conversation
We requested a meeting with the CEO. Just the two of us.
We came prepared with documentation: the original scope, the additions, the change log, the decision delays, the timeline impact. All of it.
Then we said something we'd never said before:
"This engagement isn't working. And continuing it isn't good for either of us."
We walked through the pattern:
- Scope changes that weren't acknowledged
- Communication breakdowns that created delays
- Accountability that only pointed one direction
- A dynamic that was eroding both teams
And we made a proposal:
- Either reset the engagement with clear expectations and mutual accountability
- Or end it professionally, transition what we'd built, and part ways
The CEO chose option two. Not with grace — there was anger and blame. But the decision was made.
The aftermath
We spent two weeks transitioning. We documented everything. We handed over code, credentials, and knowledge. We did it professionally, even though the ending was hard.
The final invoice was paid (eventually). The relationship was over.
For a while, we questioned ourselves. Should we have tried harder? Should we have been more accommodating? Did we fail?
But with distance came clarity. The engagement was never going to succeed — not because of the technology, but because of the dynamics. No amount of accommodation would have changed the fundamental mismatch.
What we learned
Values alignment matters more than project fit
Greenfield was a good project on paper. But the values mismatch — around communication, accountability, and partnership — made success impossible. Now we pay as much attention to how a potential client operates as to what they want to build.
Warning signs don't get better with time
Every red flag we ignored in month one was worse in month three. The communication issues didn't resolve — they compounded. The scope problems didn't stabilize — they accelerated. Early warning signs deserve early action.
Documentation is protection
We had good documentation. It didn't prevent the conflict, but it gave us a clear record when the conflict arose. Now we're even more rigorous about documenting scope, decisions, and changes.
"No" is a complete answer
We can say no to clients who aren't right for us. We should say no. A bad engagement costs more than an empty slot on the schedule — in stress, in reputation risk, in opportunity cost.
Ending well matters
Even when a relationship fails, how you end it defines your character. We're proud that we handled the transition professionally. The bridges weren't burned; they were closed with integrity.
The best business relationships are the ones you'd start again. If you wouldn't, that's a signal — even if the work is profitable.
What we look for now
This experience sharpened our thinking about who we want to work with. Here's what we look for:
Mutual respect
We bring expertise. You bring context. Neither is more important. If the dynamic is "vendor takes orders" rather than "partners collaborate," it's not a fit.
Communication as a shared responsibility
We'll communicate clearly and regularly. We need the same from you. If decisions take weeks and questions go unanswered, the project suffers — regardless of how good our work is.
Accountability that goes both ways
When things go wrong (and they will, occasionally), we solve them together. Blame games don't fix problems. If the reflex is to point fingers, we're not the right partner.
Realistic expectations
Technology projects are complex. Timelines shift. Requirements evolve. Surprises happen. We need clients who understand this — who can adapt without drama when reality doesn't match the plan.
Long-term thinking
We want to build things that last. Quick fixes, corner-cutting, and "just get it done" mentalities create problems down the road. We look for clients who share our long-term orientation.
How we qualify now
Before we take on a new engagement, we ask ourselves:
- Is there mutual respect? Do they listen to our expertise? Do we feel valued?
- Is communication working? Are responses timely? Are decisions made reasonably?
- Is accountability shared? When we discuss challenges, is it collaborative or adversarial?
- Are expectations realistic? Do they understand what they're asking for?
- Is this a partnership? Or is it a vendor relationship dressed up in partnership language?
If the answers concern us, we don't proceed. The engagement that makes money but drains the team isn't worth it. The project that looks good but feels wrong isn't for us.
Why we share this
Some people will read this and think we're difficult. That's okay. We'd rather be seen as selective than as accommodating to dysfunction.
The clients we work with now are partners in the real sense. Communication flows. Accountability is shared. Problems get solved together. That's what we wanted all along.
We just needed a painful experience to clarify what we were looking for — and to give us the courage to insist on it.
If you're reading this and thinking "I want a partner like that," we should talk.
If you're reading this and thinking "sounds difficult to work with," we're probably not a fit. And that's okay too. Better to know now than to learn later.
The best relationships — in business and in life — are the ones built on mutual respect and shared values. We learned that the hard way. We'd rather not learn it again.
Entvas Editorial Team
Helping businesses make informed decisions
