Ask HN: Coping when your client is an asshole?
Some people will say &quot;it&#x27;s not worth it&quot;. But if you need to pay a mortgage and take care of a family, you may have to change this to &quot;it&#x27;s not worth it forever, but I can handle it for a while.&quot;<p>I have fired 3 major clients of mine in the past 20 years. All of them started out fine, but turned so rotten and horrible I nearly quit each time.<p>But it&#x27;s not just bad clients. Even some of my ok clients can be a pain at times, mainly due to schedules and stress.<p>Here&#x27;s a few things I have found that help both with bad clients and &quot;ok&quot; clients having a bad time.<p>1. Patience and understanding: Seems obvious, but it&#x27;s possible these people that are assholes today may really be on the edge of losing their jobs&#x2F;business too. Not an easy thing to do, but takes a tiny bit of the bite out of their accusations.<p>2. Support tickets: Require (in some way) all&#x2F;some requests go through a support ticket system. I have found this can help both parties with communication, so it&#x27;s an easy sell without having to lie to them. Also, the more nasty they are, the more specific fields they have to fill out.<p>This turns a &quot;it&#x27;s broken and you broke it!&quot; into -&gt; &quot;The form shows an error when submitting from an iphone.&quot;<p>3. At the extreme level, I have stated I will only do email communication and not talk on the phone. May work or not.<p>4. Don&#x27;t answer the phone or reply to emails. Take a break for a while. I have to do this even with my ok clients. (my good clients I pick up on the first ring, and they treat me better than I treat them, or that is how it feels)<p>5. Set expectations CLEARLY. I found the biggest problems were when someone thought something was going to happen and it didn&#x27;t. After many years of software dev, I tell people up front all the things that I know in the past have caused problems.<p>For example, I say &quot;1&#x2F;3 of the budget is due up front before we start work&quot;. If they come back and say &quot;why haven&#x27;t you started yet?&quot; I can say &quot;I have not yet recieved the up-front money&quot;. And refer to the documentation. (if they haven&#x27;t read it, that&#x27;s on them and it take a little bite out of their bark)<p>Another example is changes. I state clearly in advance, any changes from the specs (depending on the project how detailed they are) _will_ change the timeline and the costs. But even with this, I offer a number of minor changes within the budget. But also, I offer free bug fixes for _fixed_ period of time. All stated plainly up front.<p>The hardest part about this? When I forget to mention something, and I have to bring it up in the middle of a problem. It doesn&#x27;t change the formula though.<p>It&#x27;s like this: Client asks for 10th change. I say that is a &quot;change order&quot; and will cost extra. Client is mad because he&#x27;s &quot;expecting&quot; it to be free. I apologize (the key here to take responsibility for my failure to communicated) for not making it clear that there are only 3 free changes, and in fact I have given 10 (demonstrate they have already gotten a deal). But I will give you one more (smooth it over some more even)<p>6. Accountability system: I had clients complain about &quot;mystery changes&quot; in their templates. I&#x27;d get viciously blamed for breaking a site. So, instead of explaining that my software couldn&#x27;t possibly create broken html tags with a random copy paste. (because I know my code) I instead installed GIT on the dang server and every save from the client stored the account info, date stamp and even IP address.<p>That ended _every_ _single_ _complaint_ about template errors. (because _none_ of them were mine, they were all the clients fault.) Imagine having to tell your client it&#x27;s their fault every time they call you? It sucks for both of you. I cannot emphasize enough what this meant to my sanity. Imagine going from a few complaints a week for months, to zero.<p>The first few times I had my client click the &quot;history&quot; button on a template and showed that it was either them personally, or one of their unskilled laborers that broke it, the accusations stopped. For ever. (I feel that relief again just writing this)<p>Since I don&#x27;t know the exact nature of your project, GIT maybe won&#x27;t help directly. But the idea might.<p>A universal CYA method would be include all client requests as part of the documentation to changes. (if this is part of the problem)<p>7. Take responsibility for your errors. I found that as soon as I made a mistake, and I owned up to it, it was easier to point out when something wasn&#x27;t my mistake.<p>8. Ask them to be polite. One client (who I eventually fired) had two partners. At the end of the relationship, one of them just sent nonsensical email rants. I asked him to talk more politely, and he out right refused. So I asked his partner to step in, but he was a big wimp and did nothing about it. Now, knowing what I know, I would simply ignore the other guys emails, and just communicate with the decent guy.<p>Sometimes playing dumb works too with these things. When you are sick of something, just ignore their replies and just keep working and doing the best you can.<p>9. The owner&#x2F;s need to step up. It hits a point where if the environment gets so bad that you start losing talent, then it&#x27;s going to hurt the owner. It would be a good show of respect to get the owner involved in the problem before it&#x27;s too late.<p>10. Build extra tooling. One project with a client (from #8 above) and sub-par developers that couldn&#x27;t follow directions or solve any problems. I built an API and all sorts of stuff, documented it clearly, yet I got blamed when their stuff didn&#x27;t work with mine.<p>My solution? I built _their_ stuff too. Or at least a very simple skeletal version of their system. Combined with multiple screen recordings of working with the API and the data. That _totally ended_ the complaints that my stuff didn&#x27;t work, because it was really, really obvious that it did. (their programmers just didn&#x27;t seem to know anything)<p>Final thought: I have found when I am teetering on the edge of falling over a cliff (despair&#x2F;rage&#x2F;annoyance&#x2F;quitting&#x2F;etc...) even the slightest bit of positive change can help me make the right decision. And making the right decision is always better in the long term. So get even small successes from any changes you can make may be all you need to get things on track.<p>This hits home for me, I&#x27;ve had such horrendous experiences with this stuff that I could write lots more. Hope you recover and everything works out. (sorry this got so long)