How to Vet a Client Before Starting: 8 Red Flags I Watch For

Two years ago I took a project where the first call had three signals I already knew how to read. I took it anyway — the money was good and I told myself I'd manage. Four months later I was walking out of that project. Professionally, no drama. But I'd spent months on work I shouldn't have started.

Not the worst experience in the career. But it's where the checklist came from.

The first conversation is already a technical decision

Developers are trained to make decisions in code. Which library, which pattern, when to start refactoring. But the most expensive decision in any project gets made before the first commit: whether to take this client at all.

I close risks, not tickets. That means before writing a single line of code, I try to understand what risks the client brings — not just technical ones. Behavioral ones.

The first call, the first email, the brief itself — these are data. They can be read.

How a difficult client's brief reads

A few phrases show up in briefs often enough that I've stopped treating them as neutral.

"We need this urgently" with no explanation why. A two-month deadline on a four-month job isn't a requirement — it's an expectation management problem the client is trying to transfer to the contractor.

"We tried before, it didn't work out." This one varies. Sometimes the previous team was genuinely bad. Sometimes the client changed scope mid-project and blamed the vendor. The answer to "what specifically didn't work?" tells you more than the fact that they switched teams.

"We want to rewrite everything from scratch." I hear this about Bitrix stores constantly. Sometimes it's the right call. More often it's rewrite fever — frustration with a system masquerading as an architectural necessity. I once turned down a $40K contract specifically because a year of server logs gave no grounds for a full rewrite, only targeted refactoring. That story is in I turned down a $40K rewrite contract.

Three types of difficult clients

The first type I call "switchers." These are clients who've already had two or three vendors on a similar project. Each time, the vendor "didn't deliver" or "disappeared." Their emails say things like "we've been burned before," "reliability is critical," "we're looking for a long-term partner." The last one sounds like a green flag. Combined with a history of frequent team changes, it isn't. The question isn't whether they want a long-term partner. It's why the last three didn't become one.

The second type are "experts." They already know the solution before I've started studying the problem. "We need headless with Next.js, Redis, here's the feature list." The spec is written as a list of technologies, not business goals. The issue isn't that they've read about headless. It's that when I say "this architecture isn't right for your situation," they'll hear "this developer doesn't understand us."

The third type are "speeders." The project was needed "yesterday," any discussion of architecture looks like wasted time. I recognize them by phrases like "we'll sort out the docs later" and "let's ship first, clean up after." Technical debt isn't created by bad code. It's created by a culture of "ship first."

First call: I ask for reactions, not answers

On the first call I ask three questions — and what I'm watching for is how they respond, not what they say.

"Who on your team will be the final sign-off on the work?" If the answer takes more than thirty seconds, or if it turns out there are multiple people with no single owner, that's a risk. Approval loops kill velocity faster than any technical problem.

"What happens if the launch slips by a month?" A good response: a specific answer about the consequences, even if they're unpleasant. A bad response: "that's not possible" or immediate pressure. When a client can't calmly answer a hypothetical about a delay, they're not managing project risk.

"What does success look like for you in six months?" Some clients talk business outcomes — conversion, speed, fewer support tickets. Others talk features: "the list, all checked off." Both are workable. The approach is just different.

My 8-point checklist before signing

I run through these before every new contract. Not all of them are red flags — some are just clarifying questions.

Is there one person who makes decisions on the project? If not, who is it, and is there a chance to meet them before signing?
Was there an agency or developer before me? If so — what happened? The reaction to this question matters more than the answer.
Are there written requirements, even just a list? "We'll explain as we go" doesn't work for any project longer than two weeks.
How do they talk about the previous vendor? If it's "incompetent frauds" — I think about what they'll say about me in a year.
How did they react to the price — and how? Negotiating isn't a bad sign. A bad sign is when the price is received as an insult or ignored entirely.
Do they understand the difference between "done" and "live"? I ask directly. Technical debt in plain money is a conversation worth having before day one.
How fast do they respond to emails during the negotiation phase? Three days without a reply isn't forgetfulness. It's the work tempo.
Have they worked with IT contractors before? A first digital project needs more hand-holding. That's not a dealbreaker, but it needs to be budgeted into the timeline.

When the signals are mixed

Sometimes two or three signals are there, but the project has something real — an interesting problem, an honest budget. You can tell the client actually cares. I don't automatically decline everyone with red flags.

What I do is name the risks out loud on the first call. Not as an ultimatum — as a working conversation: "I can see the deadline is tight. I want to understand what happens if we don't hit it." The reaction to that conversation is the most accurate filter of all eight checklist points.

A client who's willing to discuss risk before signing is a different client than one who avoids that conversation.

Closing

The first call isn't sales. It's diagnosis. The goal isn't to be chosen. It's to choose well.

Closing risks, not tickets means seeing where real losses come from. Sometimes they come from bad code. More often they come from a project with the wrong client that shouldn't have been started at all.