One of those, letting the client go turned out to be a huge mistake, since the reasons turned out to be a temporary blip. In so many words, the great executive later returned, some things that were concerning/unacceptable while the exec was away were presumably reversed, but I'd already moved on.
Another, they just had an unsalvagable massive mess of a code base that an undergrad made, and they didn't appreciate how bad it was, and that it needed more than incremental work.
Before and after the regretted cut-loose client, I also didn't take on at least a few clients who I had misgivings about. Some of those were probably due to once-bitten, twice-shy.
Some problems I've learned to avoid, and I'll phrase them here as positives (I've found both the negative and positive examples):
* Clients who realize they need more than a low-end programmer. Like many people, I have a lot of experience working higher-end than that,
* Client respects you as an expert or competent professional. That doesn't mean they defer to you automatically. What you want to avoid are situations like someone key at the client thinking they always know better, on all topics. Which is a not-unusual phenomenon. One version to avoid is when they are the expert on all things, and they think they're only hiring worker drones to save time on things they know better on.
* Client is intelligent and constructive. If they're saying technical things that don't make sense, and when you attempt to discuss, to understand and possibly inform, you hit a brick wall, then you might have a lot of brick walls in your future if you take them on as a client.
* Client has enough money, is willing to spend it on you, and looks like they'll have enough money for a while. Complementary to this, I of course wouldn't take a contract like, say, someone self-funding a startup, and no matter what I did for them, it didn't look like they'd be viable.
* If client is a CS-ish professor (which I bump into probably more than most, since I have a fondness for some aspects/ideals of universities, and live in university neighborhoods)... Only take the client if you can find a situation close to that of a colleague of mine: works with a PI who respects him as both skilled and as a collaborator. It's not uncommon for a CS-ish professor to think they know more about practice than practitioners, and they get some (misleading, incestuous) validation from others in academia. I respect professors by default, and some are close friends, but egos and inaccurate perceptions about the world outside academia seem not-unusual. Also, universities are accustomed to cheap, captive labor (except for select higher-ups, and sometimes endowment hedge fund managers).
* Watch out for the casual oracle (I don't know whether there's an existing term?), and also be careful not to be the casual oracle. By which I mean a decision-maker has a friend or someone who they keep going to to check things you tell them, and this person overrules you. Normally, this would be fine, especially as a discussion, but what I'm talking about is like a rogue doctor, who diagnoses patients without ever having examined them, talked with a doctor who has, or even glanced at their ED chart, yet ends up overriding the actual doctors of the patients. I've seen this a few times firsthand (in tech, not with doctors), so it seems to be a thing, and I also had a friend once quit over it. If it's a thing, I don't know whether it's only an artifact of not respecting the person doing the work, or something else. A few times, I've also realized that I was being asked to be the casual oracle, and I tried to be humble and qualify, but now that I recognize this thing, I'll be even more careful.