Do you vet your clients for suitablility before working with them? Maybe you should for happier freelance career.

I've started reading Book Yourself Solid as part of my daily reading. It's time I started taking my career more seriously and invest some of my time in marketing and promoting myself. At first I didn't know where to start but seeing as Curtis McHale has mentioned this book so often and his career is flying then it must be a good indication of its impact.

The first section of the book is about laying down the foundations to build upon. The first chapter is about trimming your clients down to only the clients that you want to work with. While my client list is fine at the moment, there may come a point in the future where I have a client that isn't a good fit for me. Rather than letting myself be saddled with difficult or problematic clients in the future, I need to perfect my red velvet rope policy which is mentioned in the book. Your red velvet policy is a guideline to the ideal clients you want to work with. Before accepting any work from a new client I need to decide if they are the ideal client for me.

In Book Yourself Solid, Michael suggests you identify the types of clients that you don't want. In doing this you end up with a list of traits of clients you do want. This is my ideal client in the three simplest terms that I could think of. They don't cover all aspects of a great client but it's a start.

My ideal client has interesting projects to work on

During those first few meetings between yourself and a prospective client you should get as much details on the type of work you would be doing with the client. It's here that you can get a good sense of what projects they have. As a web developer it might be tempting to always take greenfield projects on but these don't necessarily mean that they are great projects to work on. In the early days of any greenfield project there can be technical issues with untested technology such as programming languages and frameworks, dependency issues with hardware and even implementation problems if you are expected to lead a team of developers who have never used this particular technology before.

In Chad Fowler's book, The Passionate Programmer he mentions the legacy technologist who is familiar with ageing frameworks and languages and is able to work with legacy projects without a problem. These people are essential as they can nurse projects through their final years before the software is upgraded or replaced. I know many developers who would quickly sidestep projects like this but having seen the importance of technology specialists in this field from my ERP days, it's not only work that is essential but also interesting.

Legacy have their problems but what's so interesting about them is the chances that are available to refactor them or gradually migrate them over to other applications. In my days as an ERP developer I not only maintained a number of legacy ERP systems I also has the chance to provide and support and knowledge on these legacy systems to clients. It was rewarding work helping out people with their problems and fine tuning the system so that the same problem couldn't be replicated in the future or at least improved slightly.

My ideal client communicates often

Having worked on a number of projects with different clients, one of the best pieces of advice that I have had is that you should communicate with your client often. For me it's every day. Not a day goes by where I don't ask a question, drop them an IM, an email or even schedule a phone call to discuss something about the project. I used to hesistate in the past about doing this on a daily basis, but now I see it as acceptable behaviour. If I'm continually communicating with the client to clarify requirements on the project then I'm doing both of us a big favour. We're making sure that both of us don't get the end of the project and then think, "That's not what we wanted.".

However, the same goes the other way. Just like I communicate with my client frequently, I expect the same from them. If they have a question they should drop me a message or an email. If they want me to sit on a meeting, then tell me the date and time. If they want me to discuss further options then they should ask me too. I'm not a mind reader but I do try and pre-empt what the client wants. For the rest of the time I expect the client to ask questions when they need to, send me updates to the project and anything else that keeps me in the loop.

My ideal client pays on time

An obvious one for many freelancers but it's one of the key points in ensuring you enjoy your career. I've wrestled with this in the past and I've had clients that have paid on time and clients that have paid late. It's can be frustrating.

Lately though, more clients have come round to paying invoices on time. It's such a boost to your confidence and productivity knowing that your work is valued and that you will be paid for it when you expect it.

I haven't got to the stage where I have parted ways with a client over late invoices but it is something at the back of my mind that I do think about. I'm happy to report though that my client list all pay on time.

These are just three basic guidelines to the kind of clients that I want to work with. Ideally I would like to narrow this further by a specific market, but that's for another day.