How to Spot a Bad Client Before You Sign Anything

by Arif Ikhsanudin, Backend Developer

The patterns that predict a difficult client engagement almost always show up before the contract is signed. The question is whether you are paying attention.

Pre-Engagement Behavior Is a Preview

The way a potential client behaves before the contract is signed is the clearest possible signal of how they will behave after. People do not perform professionalism during the sales process and then reveal difficult behavior once you are working together. They show you early — in how they communicate, how they respond to professional questions, how they treat the process of bringing on a contractor.

Contractors who have been in difficult engagements almost always recognize, in retrospect, that the signals were there. They chose to rationalize them because they needed the work or found the project interesting. Some of those decisions were reasonable gambles. Some were expensive mistakes.

The Most Reliable Warning Signs

They are hard to reach before you are even hired. If getting a response takes days during the sales process, it will take longer when you need an approval mid-project. Communication pace tends to slow once the urgency of signing someone is removed.

They push back aggressively on basic professional terms. A request for a deposit, a written statement of work, a clear termination clause — these are standard. A client who reacts badly to them is telling you that they either have experience taking advantage of contractors who do not use contracts, or they are operating with a level of informality that will cause problems.

They cannot explain why they need this right now. "We just need it done quickly" without any context for the urgency. Genuine urgency has a reason — a launch date, a board commitment, a market window. Artificial urgency is a pressure tactic.

They describe past contractors in uniformly negative terms. One difficult contractor is bad luck. Two might be a pattern. Three or more is almost certainly a data point about the client. Ask specifically: what would have made those engagements better from your perspective? The answer is illuminating.

They minimize the complexity of the work. "It's pretty straightforward — shouldn't take long." When you know from the technical requirements that it is not straightforward. This signals either a mismatch in understanding (fixable with a clear scope conversation) or a deliberate minimization to anchor expectations and price (a red flag).

The Signals That Are Ambiguous

Some signals require interpretation:

Slow to respond during the process. This can mean disorganized, busy, or genuinely disinterested. A quick check — "I know you're likely busy, just wanted to confirm the timeline before I proceed with the proposal" — distinguishes between these. If they respond quickly to that, the earlier delay was probably just noise.

Vague about budget. Could be legitimately uncertain (early-stage, waiting for approval, genuinely not sure what this should cost). Could be deliberately withholding to anchor you. Asking a direct question — "Are you working within a specific budget range for this?" — tells you which.

Strong opinions about the technical approach. Sometimes a client who knows exactly how they want it built is a good client with informed preferences. Sometimes they are an obstacle to doing the work correctly. The tone of the conversation usually clarifies which.

When to Walk Away

The calculation is simple: if the signals of a difficult engagement are clear before you sign anything, the engagement will be more difficult after. It will likely take more hours than scoped, produce more friction than anticipated, and be remembered with frustration.

Some difficult engagements are worth taking — the rate is excellent, the project is strategically interesting, the difficulty is manageable. But taking them should be a deliberate decision, not a failure to notice the warning signs.

The most important professional skill in contracting is knowing which opportunities to say yes to — and that requires being honest about the ones that do not look right.

A bad client rarely surprises you — they usually tell you what they are before you sign. Listen.

Scale Your Backend - Need an Experienced Backend Developer?

We provide backend engineers who join your team as contractors to help build, improve, and scale your backend systems.

We focus on clean backend design, clear documentation, and systems that remain reliable as products grow. Our goal is to strengthen your team and deliver backend systems that are easy to operate and maintain.

We work from our own development environments and support teams across US, EU, and APAC timezones. Our workflow emphasizes documentation and asynchronous collaboration to keep development efficient and focused.

  • Production Backend Experience. Experience building and maintaining backend systems, APIs, and databases used in production.
  • Scalable Architecture. Design backend systems that stay reliable as your product and traffic grow.
  • Contractor Friendly. Flexible engagement for short projects, long-term support, or extra help during releases.
  • Focus on Backend Reliability. Improve API performance, database stability, and overall backend reliability.
  • Documentation-Driven Development. Development guided by clear documentation so teams stay aligned and work efficiently.
  • Domain-Driven Design. Design backend systems around real business processes and product needs.

Tell us about your project

Our offices

  • Copenhagen
    1 Carlsberg Gate
    1260, København, Denmark
  • Magelang
    12 Jalan Bligo
    56485, Magelang, Indonesia

More articles

How to Read a Query Execution Plan Without Getting Lost

Execution plans are the ground truth of database query behavior — learning to read them quickly identifies bottlenecks, incorrect cardinality estimates, and plan choices that look reasonable but are costing you seconds.

Read more

Stop Creating Branches You Never Clean Up

Stale branches are not just clutter — they create confusion about what is active work, slow down tab-completion, and make it harder to understand the state of the repository at a glance.

Read more

Memoization in Ruby — Patterns I Use Every Day

The ||= idiom covers 80% of memoization cases, but the other 20% — falsy values, arguments, thread safety, invalidation — is where the real decisions live.

Read more

Designing Thread-Safe Classes in Java — Confinement, Immutability, and Synchronization

Thread safety is not a property you add after the fact — it is a design decision made at the class level. Three strategies cover nearly every case: confinement, immutability, and synchronization. Here is how to reason about which applies and how to apply it correctly.

Read more