Evaluating A Xojo Consultant

We had an interesting conversation with a prospective client last week.  Well, I should back up and say this isn’t the first time we talked to them as we were a finalist for a project of theirs two years ago.  Turns out their Xojo consultant is having a hard time completing the work and not giving them deliverables in a timely manner.  This is for a project we estimated at less than six months worth of work.

The client is looking for someone that could come in and complete the project for them.  They were hoping that a large majority of the work could be reused.  My response was that this was unlikely for several reasons.  The first being that they used their own kit which means a set of classes, subclasses, and libraries that we are unfamiliar with and for me to use them without serious investigation (i.e. time and money) would be less than ideal.  Plus, if I’m the developer for the project I’m now responsible for it working and I’m taking a gamble on code that I don’t know and haven’t vetted.  

My second thought was wondering if their overall design had been the cause for some of the delay.  Perhaps they coded themselves into a corner.  It’s an awkward conversation to have with a client – especially after they’ve spent a boatload of money.

Regardless, I’m sure our conversation was not what the client was looking for.  They wanted a project savior because their consultants had deceived them in their capabilities and in their ability to deliver.  

We politely asked who their consultant was and they told us.  A brief internet search pulled up the company website and their *one* Xojo related post.  Everything else on their website is hardware and .NET related.  If I was evaluating a Xojo consultant that would give me some pause for concern.  You really want a consultant that does a lot of Xojo projects.  Xojo is not like .NET or Java or any other language.  It has its own set of strengths and weaknesses (just like every other language) and I’ve seen it all too often where a developer tries to make Xojo do what <insert language here> does.  It’s almost always a disaster.

We’ve been using Xojo for over 16 years.  If I’m not friends with most of the Xojo consultants out there I at least know of them and their reputation.  I have lost bids to my competitors and if the prospective client will tell us who they chose I can at least give a thumbs up to those that I know and trust since I know the client will be in good hands.  For those that I don’t know I don’t give any opinion.  But it’s also been my experience that those consultants that stick around are good and are active in the community.

If you’re hiring a Xojo consultant you should always ask for references.  If you’re going to spend tens of thousands of dollars (or more) with them you should do a little homework.  Don’t buy their assurances.  If they are really reliable then they will find references for you to check out.  This will let you know if they do good work, are on time, and on budget.  Are they reliable?  Are they hard to work with?

If you’re new to Xojo consulting that’s okay too – we were all new once.  Be honest with the client and do your best to prove to them that you’re up to the challenge.  

The Xojo community is very accepting and the forum is filled with developers that have provided answers to newbies, provided source code examples, and even established public repositories to share their code.  Have they spoke at any Xojo developers conferences?  Written for Xojo Developer magazine?  This public work can, and should be, part of the reference list.  This shows the prospective client that you really know and work with Xojo.

Hiring a Xojo consultant isn’t that difficult.  There are a number of qualified consultants that will create a great project for you.  The first step is to fill out the form at Find a Developer page on the Xojo website at https://www.xojo.com/resources/consultants.php.  This will get your project in front of everyone looking for work.  Then it’s up to you.

Ask about their Xojo work they’ve done in the public.  Ask for their references.  Heck, ask them what they love and hate about Xojo (that might be a long conversation).  If you don’t do your homework you might be wasting an opportunity in not getting your project to market, or waste tends of thousands of dollars for work that doesn’t get delivered.

6 thoughts on “Evaluating A Xojo Consultant

  1. Maybe Xojo Inc. could host a consultants list on their website?

    This could provide a global list of consultants and provide some trust.
    Maybe requirements could be to have Xojo Pro license for current version.
    There could be checkmarks for:

    * Has spoken at a conference
    * Has published an article about Xojo
    * Has shown a non trivial project
    * Has 2 years of experience with Xojo
    * Has good reference from three clients

    And maybe a requirement to have at least 3 out of 5 checkmarks to be listed?
    This could be some work for Xojo Inc. (maybe Paul?) to do this and keep up to date, but it could lead to a grown visible consultant network.
    Similar to the FBA stuff from FileMaker.

      • I reported it as feedback case 55135.

        We may talk about it at XDC with them.
        But unless someone wants to do it from outside Xojo*, it is up to them to decide what they want.

        For the visibility of such a list, it needs to be linked on various places from Xojo website.

        * Marc Zeedar could of course do this and publish the updated list in the magazine each issue.

  2. Given that most clients allegedly don’t care what language their software is written in, I was wondering how clients who specify one are different. Or is that the difference between off the shelf jobs and bespoke?

    • I don’t think your supposition is correct. A vast majority of our Xojo clients come to us knowing they want a Xojo application. They had done some research on cross-platform application development and found Xojo and believe that it would meet their needs.

      For some they feel that they might be able to do some minor editing themselves in the future. For some it’s the Rapid Application Development. I’m sure there are other reasons too.

Comments are closed.