Hartley Brody

As a consultant, sometimes it can feel like every client is out to make your life miserable. Over the past three years of consulting, I’ve lost count of how many “bad” clients I’ve worked with.

That doesn’t mean most clients are intending to be difficult. Most likely, they have never worked with a consultant on a project like this before, and they don’t understand the mindset and behaviors they’ll need to have in order to reach a successful outcome working with you.

In this case, you can work with them to manage the project and have a good outcome.

Sometimes though, it’s just a bad fit. We’ve all worked with someone who is disorganized, undisciplined, inconsistent or generally bad at communicating. They lose track of things, don’t follow up and are usually a burden to anyone who has to work with them.

These are the nightmare clients you’ll wish you never brought on.

Learning when to say no to a potential project – and when to push back firmly against bad behaviors that your clients are exhibiting – is important to have more control over your work, and ultimately, your life.

A well aligned client is a privilege to work with, and a poor one can be an absolute nightmare, robbing you of your time, sanity and in some cases – your paycheck.

These are the red flags I’ve learned to look for over the years. None of these individually should scuttle a project, but a few of them should make you consider whether this project is doomed for failure or if it’s worth saving.

Sometimes you may be deep into a project before some of these situations rear their head, and your choice is either to walk away or to push back firmly against the bad behavior to help save the project.

Here’s what I always keep an eye out and look for:

—

1. Cheapskate

In American culture, we’re taught that talking about money is taboo. The reality is that establishing your client’s budget – and their funding sources more generally – is one of the most important things you can do to ensure you’ll be paid fairly for your time.

Is this client VC-backed and generating revenue or is the budget coming from someone’s personal life savings plus some friends and family investments? The answers to those questions not only give you a sense of the size of their budget, but also how much they’ll agonize over every invoice.

I try to bring this up on the first call with a client – I have a weekly rate, I expect to be paid a two week deposit up front to hold your project on my schedule, and I invoice every two weeks.

Sometimes clients will push back: “I just need a few small tweaks to some existing software, you’re going to charge me that much?” If they’re the ones asking, the answer is always yes. If they’re going to be occupying my mindshare that week, they’re going to pay me for it.

A good line I try to use with clients is “I’m probably not the cheapest person to do this work for you.” If a client bristles at that, it’s a clear sign that they’re going to try and extract every last penny from you and you should probably steer them to a site that offers cheaper, overseas freelancers instead.

2. Can’t Follow Up

This one is always baffling to me. If a client doesn’t care enough about their own project to respond to my messages and help me figure it out, then why should I care about it?

This is probably the most common thing I run into and it can happen at any stage of the relationship. It’s one of the few red flags that you can notice early on, and save you the headache of taking on a non-responsive client that inevitably leads to a failed project down the line.

Most commonly, it goes like this:

• Clients will reach out telling me about their project and asking if I’m interested in working on it.
• I follow up with some questions about it.
• Client never responds…

Some people might think to follow up and hound the client – after all, it could be a potential project! – but if the client can’t be bothered to keep basic lines of communication going, that will spell trouble for any project, and it’s best to steer clear and avoid them altogether.

If we’ve gotten a decent way into spec-ing out the project and they go dark, I may give them a courtesy follow up a few days later in case something happened – maybe they started to respond and got distracted, life happens.

But if I’ve followed up twice and not gotten anything, I’ll let them know that we can resume the discussion in a few months when they have more bandwidth to manage the project effectively.

3. Won’t Follow Basic Instructions

One of the things I’ll often do early on in a client relationship is to give the potential client some simple tasks and assignments as I’m getting up to speed. These are usually to help them brain dump their project and ideas into some basic format that makes it easy for me to boot it all into my brain so that we’re on the same page.

You probably send clients basic assignments already, things like:

• here’s a bullet pointed list of question in an email, can you answer them for me?
• why don’t you send me what materials you’ve already put together?
• I wrote up a spec based on our call in this google doc and I left some questions as comments, can you respond to those?

I’ve found that some clients don’t really care about what you’ve told them you need from them. Instead, they will respond in some completely random way, ignoring the majority of your questions and spouting on about stuff that seems more relevant to them.

Either that, or else they can’t be bothered to follow instructions and prefer to do things their own way.

Regardless, this does not bode well for having a productive, working relationship. Down the line, this will likely manifest itself as them sending you massive emails rather than having threaded discussions in your task tracking software, leading to key details getting lost or questions going unanswered.

Save yourself the headache and steer clear.

4. Can’t Keep a Schedule

Sometimes things come up and your client has to miss a meeting with you when an important investor drops into their office. That’s understandable. But clients who make a habit of this are trouble and should be avoided.

Usually what will happen is they’ll miss some scheduled call you had, and then follow up the next day asking if you can drop everything you’re working on and call them in 5 minutes.

This is a sign of general chaos, poor communication and a general inability to empathize with how their behavior impacts other people.

These people may be egotistical executives who are used to having their minions run around for them at the drop of a hat. Or they may be more sympathetic – frazzled and over-worked employees, and you’ll be tempted to cut them some slack.

But if they routinely demonstrate that they don’t have control of their schedule (or won’t respect yours), then save yourself the trouble and pass on the project.

5. Tech Faker

Sometimes I’ll get emails from folks who seem to have a bunch of specific technology decisions already made. Usually, these will be engineering folks who have decided on a tech stack already for various reasons that generally make sense and seem reasonable.

But I’ve also gotten emails that list very specific technology requirements, and when I ask why they were chosen or what the requirements are that lead to those decisions, it’s easy to see that the person has no real idea why.

Sometimes, these folks don’t know any better and are willing to reconsider the technology if you can explain to them why another option might be better. Maybe they had a tech friend who was very blustery about the “right” way to build their application, and they scribbled down all the buzzwords, hoping that would help their chances of success.

But sometimes the client will really stick to their guns with using a particular tool, library or service, even when they have no real understanding of why that’s a requirement

Client: We need to use Postgres because MySQL isn’t good enough

Me: …isn’t good enough at what?

Client: …

It’s important to try to dig in and find out where these requirements are coming from. Maybe the client has a nephew who offered to support the project once you’ve built it, but he only knows PHP and wants it to be written in that.

If they won’t be forthcoming about how they’ve chosen the technology requirements, then they don’t trust you enough to have a good working relationship.

6. Master Architect

It’s understandable that clients are really worried about their project going well. They want to do everything they can to ensure a good outcome for the money they’re spending, but sometimes that enthusiasm can go a bit too far.

They want to have 3 hour phone calls every day where they dive into every detail and every contingency. Dev work can’t begin until the backlog for the next 3 years is fleshed out and there are specs and mockups for everything.

And while I’m usually a fan of doing more planning, not less, there’s definitely a point of diminishing returns. I’ve been through enough projects that have evolved over time to know that the plan is the point from which you deviate and getting too hung up on the planning phase leads to nothing ever being shipped and everyone being unhappy.

With these clients, I usually try to refocus them on their business goals for the project – what does a successful outcome look like in their mind? What would they consider to be “money well spent”?

Maybe it’s growing revenue or users or launching before a big tradeshow for the PR. Then I try to help them pare things down until there’s a minimum viable product (MVP) that’s no more than 2-3 months of dev work.

After that, we can launch, add features and iterate, but we’ll be able to get feedback from real people about what they like or don’t like, rather than guessing while heads-down, writing code in a vacuum. This is the more reliable path to a successful project.

7. Premature Optimizer

Some entrepreneurs have grandiose dreams about how successful their project will be – especially when they’re trying to build some mass market consumer platform – “the next facebook!“

They’ll come out swinging about how the software will need to support 100,000 users right off the bat and then grow to over 1,000,000 users within the first 6 months.

I think this is usually a symptom of clients who have spent a bunch of time pitching their idea to investors, where they need to sell its potential success to get people excited and onboard with the idea.

But from a technical standpoint, those numbers are far less exciting. “Premature optimization is the root of all evil” as the famous Donald Knuth quote goes.

Building web applications at scale can require all sorts of tradeoffs that will make adding and managing new features an order of magnitude more difficult. This can be a death sentence for a new product that needs to be nimble and adapt as reality sets in.

I usually tell first-time founders that they’ll likely end up throwing away the first version of their codebase if the product is actually as successful as they imagine it will be.

Once they truly hit scale, the implementation of their project will look almost nothing like how they (or anyone) originally imagined it, and there’s no use trying to make incorrect software more efficient.

Aside from following general best practices, it is very difficult to optimize for things when you don’t have any real data about where the inefficiencies are in your software. You can try to make guesses, but those will often be wrong.

In any new software project, you should be optimizing for the speed of adding features and changing things, not the code’s execution time.

8. Endless Tweaks

The tweaker is someone who likes to put their signature mark on every little thing. This is probably what many people would consider to be micromanagement, but it’s a particularly obnoxious form of it that can hamstring a project and add lots of delays.

They want to fiddle with every little detail, when those changes add no benefit to the final software. They’ll want to change the radius on the buttons, and then change them again once they see how their original request looks. Every single aspect of the project goes through at least two revisions before they’re happy with things.

This not only expends wastes development cycles, it’s also a large source of frustration. I usually ask that cosmetic interface tweaks wait until the end of the project, and then have them sent over in one big batch, rather than coming in bit by bit as things progress.

9. Bike Shedding

A client who is a bike shedder is someone who spends an inordinate amount of time focused on relatively trivial details, while ignoring the larger, much more important decisions.

The term “bike shedding” comes from a story:

the example [is] of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bike shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.

There are certain aspects of software projects that everyone feels entitled to give their opinion on – logos are a big one, but so are fonts, colors, button sizes and lots of other interface elements.

Even if someone knows absolutely nothing about software, they can look at a button on a screen and find 2-3 things that they believe are “wrong” with it. But if you were to ask that same person about the database design or the caching layer or whether any users will actually use this page at all, most people will glaze over and redirect back to their more secure footing – “but the buttons are too big!”

It’s important to recognize when a client is bike shedding and be firm that you need to focus on more important details right now.

10. Head in the Sand

A client with their head in the sand is someone who doesn’t really pay attention when the situation with the project is changing. They don’t want to get into the details and just repeat their same old platitude as if it is some wise riddle that contains all of the answers you need.

A very common occurrence is:

Client: Make the interface look like the mock ups the designer prepared

Me: Well, I’m trying but the mockups are ambiguous. I don’t know how these columns are supposed to scale across various screen sizes. There’s also no information about hover states or how we’re supposed to reflow things if the user collapses this section of the page.

Client: Just make it look like the mock ups and we’ll be fine

Me: …

The client is essentially telling you that all previously laid plans are sufficient, even when you’re telling them that you need more information, or that some of the assumptions you originally made have changed.

11. Man Behind the Curtain

One of the battle scars I’ve earned over the years is a line that I now include in all of my contracts – the designated point person.

This person must be the project owner on the client’s side and must be the one who has the final say over how the project goes from the client’s perspective. While I’m happy to interface with other folks at the client’s company when it’s helpful, if there’s anything conflicting that I’m hearing, I’ll always run it by the designated point person for the project.

However, sometimes you’ll find yourself in a situation where this point person isn’t actually in charge. There can be all sorts of various issues at the client’s organization that may be causing this, but the consequences are the same – any understandings you may have with your point person can be overruled by someone else on a moment’s notice.

It’s happened before where I’ve had a 3 hour call with a CTO, laying out a plan for a small MVP that will allow them to ship quickly and start testing with users. But the next day he comes back and says he discussed it with his CEO and they actually want me to work on the 3 year master plan instead. All of the time I spent reaching an understanding with the CTO was whisked away in a moment by someone else that wasn’t at the table during the discussion, that I had no chance to talk with.

Don’t let the chaos at a client’s company spill over into how you work. There’s really no saving these kinds of situations – if you can’t trust that what a client is telling you will still be true the next day, it’s best to walk away.

12. Extortionist

I’ve had the good fortune to only encounter one of these clients in the past 3 years of consulting – someone who insisted that the work wasn’t done according to their arbitrary, poorly defined standards, so they won’t pay. He likely had no intention of ever paying me for the work I was doing for him.

This was a mistake I made early in my consulting career, and something I work hard to ensure never happens again. I structure all of my projects now in a way to weed these people out – payment up front for two weeks of work as a deposit, and NET-7 payment terms on all future invoices. If they’re more than a week late on a payment, I stop working.

Never, ever start a project with a new client until they’ve paid you – especially if you’re noticing any of the other red flags mentioned.

The best thing for dealing with these thieves is to walk away from the project. Don’t beg or do anything vindictive to their codebase. They’ve demonstrated that they don’t respect you or value you, and are outright stealing from you.

Simply tell them you won’t let them waste any more of your time and this will be the last email they’ll get from you.

When it happens to you, learn your lesson and add a few red flags to your list so you know what to look out for next time.

–

This article is part of a series I’m writing in an attempt to open source my consulting business – sharing the lessons I’ve learned and the tactics I use to find good clients and keep them happy.

You should subscribe if you’re interested in getting my next article! 👍