A couple of weeks ago I did a blog post about evaluating Xojo consultants. I think if you’re hiring a Xojo developer the consultant should clearly be an expert in Xojo and should be able to publicly show why they deserve your hard earned money. But, there are two sides to the equation and I didn’t talk about evaluating the prospective client. Here are some of the things that are red flags to us and maybe why we should steer clear of them.
Does the prospective client have a clear idea of what they want? We’ve had clients that had a mere paragraph of content but could clearly articulate what they wanted. Other clients have written an 80 page document full of meaningless gibberish that required a three hour face-to-face meeting to understand it.
This is hard to evaluate but I’ve learned that if I can’t understand what the client wants and needs within a reasonable amount of time we’re not a good fit. Either they can’t articulate what they want or it means that we’re just having communications issues. It’s also possible they don’t know what they want and they want us to figure it out for them (which is a completely different project).
Has the prospective client worked with other Xojo developers before and been unhappy with the work? Don’t get me wrong, we’ve picked up a lot of happy long-term clients and projects this way. The client worked with another Xojo developer that couldn’t finish the project for a variety of reasons (like going back to a corporate job, or they bid too low and couldn’t live on the resulting income).
This is hard to evaluate too and you have to take it on a case by case basis. Listen for the reasons why they were unhappy with the consultant. Do their reasons seem petty or legitimate? Do they accept at least some of the responsibility or do they put it all on the consultant? Reasonable clients will accept partial responsibility. The unreasonable clients, and the ones to stay away from, blame everything on the consultant.
The prospective client thinks they can do some of the work. They have experience in <x> language and want to implement some of the work in Xojo on their own. Or they feel their proof of concept project written in <x> language should give you a huge leg up on the overall project.
As with the previous points this is hard to evaluate. Xojo is an easy to learn language but it’s been my experience that making Xojo work like <x> language is a recipe for disaster. Xojo is Xojo and not like java or FileMaker or anything other language or environment. Maybe their work helps but mostly it probably won’t. It’s just easier to assume it’s going to be a complete rewrite.
The flip side to this is there are some clients that really are competent developers – just not in Xojo. We’ve done a number of projects where we start the project for them. We complete the basic infrastructure and give them some example List and Edit forms whatever else they want help with and then turn it over to them to complete the rest of the project. They usually come back with some questions but for the most part they finish it themselves. I consider this as part consulting and part training and we put more comments into code so they can understand the code better (since they’re learning).
The prospective client is always fighting with you about money. We’ve had clients that want estimates on features so they can get their project done as cheap as possible. I don’t begrudge any client that wants estimates on features to save money, but there are those clients that always complain about every penny and fight you on estimates and change orders and demand proof for every little thing. They also tend to hold you to the dollar on any estimate you give them.
We had one prospective client that came with a project written by another developer. It was referred to us by a Xojo consultant leaving the industry and couldn’t help them. The project had a silly design where the SQL query was a staggering 200 pages when copied into a text editor. It literally took minutes just to create the query and many minutes for the database to return results. The only way to really clean it up and make it work properly was to break it up into smaller queries. It would have given them more flexibility and it would actually speed up their entire process rather than locking the app up for minutes at a time.
Regardless, we came up with the estimate to fix it. They said it was too much money and we parted ways. They came back again in six months when the Xojo developer they found to ‘fix’ the query couldn’t do it (because it really needed to be broken up into smaller queries) and we gave them the same estimate. It was still too high for them. Six months later they came back yet again and asked if the price was the same. It was not because we had raised our base rates. We’ve never heard back from them and I wonder if they’re still in business.
Many clients are a delight to work with. Not all of them will be long term clients but some will. If you don’t get a warm fuzzy feeling after communicating with the client a few times you should really figure out why. You’re going to know their project better than they do so you’d better figure it out before starting a big project.
Ironically some of our longest term clients were hard to work with at first. See, they had bad experiences with other developers and were wary of being burned again. Keep that in mind too. They’re being hard on you because they weren’t with their last developer.
These are just a few of the red flags that should concern you when talking with prospective clients. What red flags do you look for?