Why We Fire Clients

Veld Systems||5 min read

Most agencies will never admit this publicly: some clients make it impossible to do good work. They burn out your team, tank project quality, and cost you more than they pay. The professional thing to do is end the engagement. We have done it multiple times, and we are better for it.

This is not about being difficult to work with. We are flexible, patient, and experienced at navigating the messy reality of software projects. But there are patterns that signal a relationship is fundamentally broken, and continuing it serves no one. Not us, not the client, and definitely not the product being built.

The Patterns That Lead to Firing a Client

Over years of running engagements, we have identified the recurring signals that a client relationship is heading toward failure. These are not personality complaints. They are structural problems that prevent good software from getting built.

Scope that never stops expanding without budget adjustments. We are happy to accommodate changing requirements. Software projects evolve. But when every sprint includes new features that were never discussed, and every conversation about timeline or budget is met with "we just need this one more thing," the engagement becomes unsustainable. We have had clients double the scope of a project while expecting the original timeline and price. That is not flexibility. That is a fundamental misunderstanding of how software development works.

Decision makers who disappear. Building software requires decisions. Which user flow do we prioritize? How should this edge case behave? What does the business logic look like for this pricing tier? When the person who can answer these questions vanishes for weeks, the project stalls. We have had engagements where we blocked on client decisions for longer than we spent actually building. That is not a partnership. We wrote about what working with a software agency actually looks like specifically so clients know what to expect going in.

Disrespecting the team. This one is non negotiable. Our engineers are professionals. They deserve to be treated as such. We have ended engagements where clients yelled at team members, made unreasonable demands outside business hours, or consistently dismissed technical recommendations only to demand fixes when those recommendations turned out to be correct. Life is too short, and good engineers are too valuable to burn them out on toxic relationships.

Refusing to pay for the work delivered. We have clear contracts and milestone based billing. When a client consistently delays payments, disputes invoices for work that was approved and delivered, or tries to renegotiate rates after the work is done, we terminate. This is a business, and we cannot do our best work while chasing payments.

Ignoring professional advice then blaming us for the outcome. We are hired for our expertise. When we recommend a specific architecture approach and a client overrides it without technical justification, that is their prerogative. But when the override causes problems and the client holds us responsible for the outcome of their decision, the trust is broken.

Why Ending Engagements Produces Better Work

This might sound counterintuitive, but firing clients has made us a better agency. Here is why.

Team morale directly affects code quality. Engineers who are stressed, disrespected, or overworked write worse code. They cut corners. They miss edge cases. They stop caring about craft. When we remove toxic engagements, the quality of work across every other project improves measurably. Our retention rate for engineers is well above the industry average, and protecting them from abusive client relationships is a significant part of why.

It frees capacity for great clients. Every hour spent on a dysfunctional engagement is an hour not spent on a client who values what we do. We would rather go deep with fewer clients who trust us than spread thin across engagements where we are fighting the relationship instead of building the product.

It builds our reputation. Counterintuitively, having boundaries makes clients trust us more. When a prospective client hears that we will walk away from money to protect quality and team wellbeing, it signals that we care about outcomes. The clients we want to work with, the ones who build real products and value expertise, see that as a positive signal.

How We Handle It

We do not fire clients impulsively. There is a process.

First, we have a direct conversation about the problem. Most of the time, this resolves it. Many of the patterns described above are not malicious. They come from founders under pressure who do not realize the impact of their behavior on the engineering team. A frank conversation fixes the majority of cases.

If the pattern continues after the conversation, we send a written notice outlining the specific issues and what needs to change. We give a clear timeline, usually two to four weeks, for improvement.

If nothing changes, we provide 30 days notice, deliver all current work, ensure a clean handoff, and part ways professionally. We have never left a client stranded. Even when the relationship is broken, we ensure they have everything they need to continue with another team.

The Signal for Prospective Clients

If you are evaluating agencies and this post concerns you, consider the opposite: an agency that never pushes back, never says no, and never ends an engagement is an agency that prioritizes revenue over quality. That means they will say yes to everything, overcommit, and deliver mediocre work.

We are not looking for clients who want an order taker. We are looking for clients who want a development partner that brings expertise, opinions, and a genuine investment in the outcome. The best client relationships we have, projects like Traderly and GameLootBoxes, work because both sides are committed, communicative, and respectful.

A good question to ask any agency you are evaluating: "Have you ever fired a client, and why?" If the answer is no, either they have not been in business long enough, or they do not have the standards to do what is best for your project.

What We Look for in Clients

Since we are being transparent about what does not work, here is what does.

Clear ownership. Someone on the client side who can make decisions, answer questions, and unblock the team. They do not need to be technical. They need to be available and empowered.

Respect for the process. Software takes time. Requirements change. Bugs happen. Clients who understand this and work with us through it get dramatically better outcomes than clients who treat every setback as a failure.

Willingness to invest properly. Good software is not cheap. We publish transparent information about what custom development costs so there are no surprises. Clients who try to get enterprise grade software on a hobby budget end up frustrated, and so do we.

Trust in expertise. You hired us because we know how to build software. The best outcomes happen when clients bring the domain knowledge and we bring the technical execution. That combination, not micromanagement, is what ships great products.

If that sounds like you, let us talk. We are selective about who we work with, and we are proud of that.

Ready to Build?

Let us talk about your project

We take on 3-4 projects at a time. Get an honest assessment within 24 hours.