Customers For Life

I highly recommend you read/watch this post: https://socialtriggers.com/lose-customers-alienate-clients/

I’ve been doing consulting work for over sixteen years and a vast majority of it using Xojo. During my time with my own clients I’ve tried real hard to keep them happy because I’ve always known that happy customers come back. Finding new clients takes a lot of effort.

I know I’m not the least expensive Xojo consultant out there and I’m certainly not the most expensive either. Our billing rates reflect what we feel is a good value. If our rates are too high for a prospective client I’m okay with not getting their business because it’s not worth it to me to compromise on that (and I’ve pointed them to other developers that I believe could help them). Sometimes they come back later and sometimes they don’t.

The post I linked to talks about getting ‘Customers For Life’. I’m happy to say that we’ve had some of the same consulting clients for well over ten years. I try to make them feel appreciated and that we listen to their concerns. When things go wrong we try to make it right. Some clients have left and I hope they’re happy with the new developer they decided to use. But a lot of them stayed and that makes me very happy.

As the post said it’s not all that hard to keep a customer. All you have to show is that you have their best interests at heart. As Maya Angelou said, “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.”

How does this all relate to the general theme of my blog? Well, it’s no secret that I’ve been unhappy with Xojo recently. I’ve felt for many years that Xojo doesn’t court people like me (consultants and 3rd party developers) with much fervor. I’ve generally been okay with that because the product works well for what I do for my customers and if they’re happy I’m happy.

The whole fiasco with API 2.0 has left me feeling rung out and unappreciated. Many of the beta testers gave their opinion and concerns about API 2.0 very early in the R2 beta and those concerns were either ignored or dismissed. Those concerns have since been confirmed by the 3rd party developers.

If you had asked me a year ago would I be this mad at Xojo? I’d say, not a chance. After all I’ve been their customer for a long time. I’d hate to add up all the money I’ve paid them for licenses, consulting leads, and conferences over that period not to mention the number of blog posts, the many hours to create training videos, and in general promoting their product. Obviously helping them has helped my business. I’d like to think my work has helped them too.

So what happens when they lose a customer for life? We’re going to find out, I guess. I’m not going away any time soon since I’m not going to abandon my consulting clients but rather than renewing annually like I’ve done for many years I believe I’ll wait until I’m forced to upgrade for whatever reason, or they release a version I can use.

I’ll still blog about the product because that’s what I do and I’ll continue to update our Xojo products because we use them too (converting to API 2.0 is still up in the air for now). Will I start looking at alternatives to Xojo? Yes because they’ve made me feel like I’m unimportant to them. They don’t want customers for life they only seem to want new Xojo developers.

Finding an alternative to Xojo won’t be easy. Despite its warts it’s still a pretty unique product. There are lots of alternatives that don’t do something that Xojo already does, but the flip side is that there are products that do some things way better than Xojo.

Over the upcoming months I’ll start letting you know what I’ve been looking at and why. It might be illuminating and it might just end up being that I stick with Xojo because I just don’t find an alternative (I doubt this but it’s a possibility). I’m looking at the overall package from the IDE, to the language, to the 3rd party market, to the consulting market. It’s a big task.

Could Xojo win me back? Anything’s a possibility. Heck, I want to be excited about the product again. I need it to succeed for my clients to succeed. But for now, I’m satisfied with 2019 R1 and looking for alternatives.

Evaluating Prospective Xojo Clients

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?

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.

Recharging the Battery

One of the ‘joys’ of having my own business is that I’m always on-call and there are times I’m answering emails on a Saturday night.  Most of the time, it’s no big deal but it can become exhausting without a break.  This is why I need to take time off and recharge my batteries.  So should you.

Carol and I did that last week with a vacation in the Caribbean.  We had a lot of fun and got a chance to recharge our batteries and get away from work (and US politics).  And even though we weren’t technically working (I consider coding to be the real work), we did talk about our business and those things we are grateful for.

One thing we are extremely grateful for is the fact that we can take off for a week without feeling guilty.  That got us thinking on why is it so hard for consultants to take time off.  It’s not too hard to figure out but here are a few items from our list (sadly the list got a Bahama Breeze spilled on it and thus couldn’t be saved for posterity, but here’s what we remember).

If you’re not working you’re not making money.  So true for consultants, but my advice is to try to develop multiple income streams so you can make money without doing consulting.  We have our developer products (ARGen and Shorts are our big ones) and without any work on my part we sold some last week.  We also have our Xojo Training videos that are income.

Having that one big all consuming project.  A lot of Xojo consultants I’ve known over the years have that one big client that consumes nearly 100% of their time.  We have multiple Xojo developers and while we can do big projects that involve all team members, it’s pretty rare.  This means that our income (and risk of losing it) are spread across multiple projects/clients.  For us, projects come and go, and that means there are times when one or two of us get to work on internal projects but our income levels stay consistent.

It’s all on you.  Solo consulting stinks because it’s all on you.  I can’t tell you how many solo Xojo consultants I’ve seen come and go in my fifteen years.  Doing it all by yourself is tough and sort of ties into the one, big, all consuming project from above.  You only have so many hours in the week to code and if you don’t have help you still have to take time out for marketing, sales, and developing multiple income streams.  It’s just not possible for solo developers to be spread that thin.

Do you have a job, or do you have a business?  Over the years I’ve had multiple solo consultants chastise me and tell me that I’m just ‘training my competitors’ with my multiple employees.  Sure, that’s always a possibility, but is it probable?  So far, they haven’t and my thinking is that if they really wanted to have their own business they’d probably already be doing it without my training anyway.  Having and running a business is not the same thing as having a job.  Plus, that type of thinking comes from fear and I’m confident enough in my own abilities and experience that it simply isn’t a concern.

Consulting rates are too low.  I’ve talked about this multiple times but too often someone new to consulting will take their last real-world salary and figure out their rate from that.  This is absolutely the worst thing to do because as a consultant you don’t have a job you have a business.  You need to have a rate high enough to pay for health insurance, retirement plans, and to pay yourself during your vacation escapes each year.  It is your responsibility, as a business owner, to calculate what rate that is for you.  If you want to know my rate send me an email and I’ll gladly tell you but I will also say that if I was still a solo developer it would be higher because I can only code so many hours in the week.

You must recharge your batteries every now and then.  Without that you become inefficient and run the risk of burning out and you’ll be sending an unhappy client to me to take care of their project.  Don’t laugh because some of my best long-term clients came from a solo Xojo developer that had to leave consulting for one reason or another.  Some left because they were charging too little to pay for health insurance, retirement, and to recharge their batteries on a consistent basis.

So what do you do to recharge your battery?  And why do you think many people fail as solo developers?

Consulting Red Flags

The one absolute truth about consulting is that if you’re not working you’re not making any money.  The corollary to this truth is that you are either 100% busy or 100% not busy.  This is especially true if you are a solo developer.  It is very hard to turn down projects when they come your way but I’ve found that there are times when you should.

I get it.  Really, I do.  If you’ve been idle for longer than you’d like and money is starting to get tight ALL projects start to look good.  Don’t take the project because you need the money.  Take the project because it’s a good fit, it’s interesting work, and you think the client will be a good partner.

In the world of make-believe this is the way it should be.  In the real-world you don’t always have those options.  Plus, it’s really hard to figure out if a project is going to be a good one or not.  Here are some of the red flags I’ve come to recognize in fifteen years of being a Xojo consultant.

Other Peoples Code (OPC).  Code written by someone else is always a red flag.  We write code a certain way and if any of our team work on it we can rest assured that certain things will be done (naming conventions, comments, etc.).  No such guaranty with OPC.  It’s way easier to start from scratch but with most OPC projects you don’t have that option.  So you start with a level of uncertainty and having to decipher not only the coding style but often times the intent of another developer.  Learning someone elses code stinks.

Project complexity.  When I’m asked to join an existing project I try to look at how complex it is.  If it’s really complex I hesitate because I know it will never get less complex.  In many cases the original developer tried to be clever to solve some (real or imaginary) problem and while solving it completely overlooked a much simpler way of doing things.  Plus, if it’s not one of your core competencies it might not be a good fit anyway.

Another item under the project complexity red flag is excessive amounts of documentation.  From experience, most projects can be summed up with a page or two of high level description and then a dozen pages of important detail.  When the client sends you a very long document with high levels of detail you might be getting yourself in other your head.

Of course the flip side of that is clients that send you a paragraph or two of their idea.  In those cases we have to draw more information out of them, and depending upon the size of the project, we might actually charge them to write their specifications for them and let them get some competitive bids from other developers.  I think the lack of detail says they haven’t done enough homework on what they want and need.

Toxic teams.  Another issue with joining an existing project is trying to figure out if the team is toxic or not.  The existing developers will always have their own habits and you, as the consultant, need to try and match theirs.  What if those habits are silly?  I’ve seen teams that require a comment for every line of code.  I’ve seen some teams that disdain any comments under the guise that code should be ‘self commenting’.  Is there a team member who’s the ‘smartest person in the room’ and everyone else has to put up with it?

Project savior.  I can’t tell you how many times I’ve been asked to look at a project started by other developers and the project owner is desperate for it to get done.  In these cases they’ve spent a LOT of money with a developer and gotten poor, or no, results.  You have to ask yourself a few questions.  Was it the developer being incompetent, the owner being unreasonable, or both?  If you take one of these projects you can either be the hero by completing the project, or you can be the goat for being just as incompetent as the original developer.

Project owner/developers.  I’ve found that working with project owners who are also part-time developers also can be a pain to work with, but not always.  The ones that come to me realizing that creating an application isn’t easy and requires time they don’t have and knowledge they don’t have time to acquire tend to be okay.  Those that say it should be ‘fast’ and ‘easy’ for someone with your skills have their expectations set too high.  Software development, in many respects, is more art than science.

Always complains about cost.  Every client wants their custom software done cheap, quick, and on time.  The industry joke is to pick two of those qualities.  Software development of custom software isn’t cheap, nor is it quick in most cases.  If they balk at the initial estimate it probably won’t get any better.  They certainly won’t like any change orders.  We had one prospective client ask us three times, over the course of a year and a half, what the price was going to be to complete their project.  I don’t know if they expected our price to go down, or what, but eventually they found a developer to do their project at the price they wanted.  And then had the audacity to come back six months later then that developer couldn’t deliver.

Been through many developers.  Perhaps my biggest red flag of them all is when someone comes to us after going through several other developers.  Listen to their complaints about the other developers.  Were they too slow, did they charge too much?  I’ve even asked for permission to contact the previous developer to get the news from the developer perspective.  The community is small so there’s a good chance I know them and I know I’ll get the developers perspective.  Use those connections if you can because you might discover some useful information about the client and the project.

Just because you need the work doesn’t mean you should take every project that comes your way.  Be selective because you’ll avoid some heartache and probably enjoy your work more.  What red flags have you developed over the years?

Estimating is an Art, Not a Science

A question that comes up quite a bit is how to do proper estimating.  It’s not an easy thing to quantify as much of involves gut feeling at times.  It’s why I feel that estimating is an art, not a science.  The hard thing about estimating is that it takes experience to know if you’re doing it right or not.

My first bit of advice is start using a tool to track your time.  If you can’t do it by specific task, as least do it by overall project.  Once the project is done you can then see if your estimate matches reality.  It won’t at first but that’s why you track your time so you can make adjustments on the next project.  After looking at several projects I came up with the idea of the times three for estimates.

When you look at part of a project, say a form, your estimate tends to be something like this:  if I know everything up front and there are no major surprises this is what is how many hours it will take to complete the programming and testing of this form.  However, we rarely know what those major surprises are up front so at best this is my guess and multiply it times three to come up with a more realistic estimate.

After a while I started to realize that some forms just aren’t going to take that long.  An About Window just won’t take more than fifteen, twenty minutes – ever – so why do the multiplier on that?  It makes no sense.

What makes one form harder to develop and test than an other?  Complexity.  A simple List form and an Add/Edit form might take an hour each (if that) to complete but busier versions of both might take three to four hours each.

What brings in the complexity?  Well, that depends on a number of factors.  Number of controls on the forms is a good start.  The business logic is another.  If how things work depend on what the user is doing in the controls you can rest assured that programming and testing of it is going to take longer than you expect.

Another part of complexity is the number of unknowns.  If you have to do a complex calculation that involves a bunch of math (especially if you’ve never done said math before) it should up the complexity.  Doing some programming concept in Xojo that you’ve never done before should up the complexity as well.  In both cases you should expect some research time, maybe even time to do a small example project, and a restart or two since you’re learning as you go.

In my initial guess I still do the ‘if I know everything up front and there are no surprises’ estimate.  And then my multiplier is my feeling of the complexity of that part of the project.  The complexity factor is now my multiplier.  So an About Window has a complexity of one.  A simple list form has a complexity of one and half, but a form with several page panels or containers that do different things based on user input might be a complexity factor of three or four (or more).

I tend to break projects down to several parts.  The first is overall project design.  There are certain number of hours just to set up the project and create the classes I need.  There’s usually some database design and implementation.  Do I need to make any special classes or subclasses for functionality that I already know about?

When it comes to the UI I often take the database design as the guide.  Each database table is (probably) going to need a List form and a way to edit it.  Figure that a list table is only going to need a few of the fields for listing but the Add/Edit form is going to use all of them.  Are they all text fields or is it a mix of lookup fields with foreign keys?  Each of these adds to the complexity of the forms in question.

Coming up with an estimate is sometimes an art.  It takes experience (and failing a few times) to get the hang of it which is why you need to track your time.  Using the complexity as a multiplier might be a good way for you to start getting more accurate estimates.

Let me know if you do something different for estimating.  How do you track your time?

Happy coding!

You Don’t Need to Be A Rock Star

I have been a Xojo consultant for nearly fourteen years.  It’s crazy to think it’s been that long and it’s sometimes hard to remember back to the early days of how I knew nothing and didn’t even realize that I knew nothing.

It also tickles me to no end that people consider me an ‘important’ person in the community.  Some might even consider me a ‘rock star’.  I claim no fame in the Xojo world other than I’ve stuck it out when many other developers have left the Xojo ecosystem.  Let’s just say that at times I feel like I’m the Last Man (consultant) Standing.

Can you become a Xojo consultant?  Absolutely!  There is nothing special about what I’ve done and you can do it too.  I have an electrical engineering degree so it’s not like I’m an idiot and it wasn’t until I met my wife who happened to be a software developer that I was given permission to change careers.

In retrospect that was the best thing that ever happened to me (besides meeting the love of my life).  I was an uninspiring engineer and I dreaded many of the tasks that I performed on a daily basis.  Software development, on the other hand, inspires me.  I wake up every day and (usually) can’ wait to start coding.  The fact that I get paid to do it is just icing on the cake.  To get paid to do what I love?  Sign me up!

If you know a little bit about Xojo you can become a consultant.  First, ask yourself WHY you want to be a consultant.  If it’s for the money don’t expect it to happen right away.  I think it was two or three years before we really made any money at it.  It took six years before I hired a second developer and ten years before a third and twelve before bringing my wife on as a software developer (she had always been doing those pesky taxes and payroll things that I hate doing).

So if you do become a consultant don’t expect to make money right away.  Or if you do, don’t expect the money to be consistent for a number of years.  Even now we fight with cash flow so it takes some discipline to ride out the really good times when cash flow is great and the not-so-good times when cash flow is poor.

The road to becoming a ‘name’ is not a quick one.  I spent many years in obscurity.  The first developer conference I went to I was a wall flower and barely talked to anyone.  By the third conference I co-hosted a session with another consultant because I didn’t feel like I was qualified enough to do it on my own.  Now I’m a regular presenter at the developer conferences.

One way to become a recognized name in the community is to teach others.  I’ve written a fair number of tutorials and example projects and I decided to doing video training and so far I’ve got about sixty-two hours of video available for streaming (and offline use now) with hundreds of individual videos and project files for new developers to learn from.

I think this is the part that makes people think that I’m a ‘rock star’.  I get people coming up to me all the time at conferences and engaging me in conversation and thanking me for some forum post, tutorial, or training video that made a difference for them.  It’s gratifying and sometimes a little scary (as an introvert) to have people do that.

Here’s my dirty little secret on those tutorials, example projects, and training videos.  Those are my way to learn something about Xojo and leveraging that experience for others.  Put another way:  The best way to learn something is to teach it to others.  If you are not doing something like this (maybe not for sale but for yourself) you should be.  That’s the only way you’re going to learn parts of Xojo you don’t know as well.  You really don’t want to learn new stuff on client projects (though it does happen occasionally).

As a consultant I don’t know everything.  There are still things that I’ve never touched in Xojo and things that I touch so rarely that I have to go relearn it.  Those small projects become invaluable review later on.

I don’t want to discourage anyone from becoming a Xojo consultant.  It’s not an easy road at times and it is sometimes frustrating and you put in long hours and you deal with bad clients and all the really bad things that come with consulting.  But the money can be good, it can be fun, it can be rewarding, and some clients you’ll be friends with for many years.  If you love, truly love, coding and enjoy the mysteries of it and putting the pieces of the puzzle together then maybe you, too, can become a rock star consultant.

Happy coding!

Xojo Webinar: Xojo Consulting

For some time now Xojo has been doing webinars on various topics.  It’s a great way to learn about Xojo.  In addition to being live (where you can ask questions) they are recorded too.  As time goes on the webinar archives become a really nice resource for new Xojo developers and even experienced developers can learn a few things too.  If you’ve never been to the archive, check it out!

Join me at the next Xojo webinar, Tuesday, July 22,  where I’m guest host!  I will share my 13+ years of Xojo consulting experience.  Learn some of the great things (and not so great things) about being a Xojo consulting.

Come prepared with questions!

Register now at http://xojo.com/support/webinar.php

Custom Programming

Does your customer really need the type of custom programming you’re selling?  I often get a request for a quote that involves fairly standard business applications such as accounting and contact management.  It’s hard to justify,  to myself at least, why they’d want to spend tens of thousands of dollars when they could spend merely hundreds of dollars on off-the-shelf software.

Off-the-shelf software has some advantages over custom programming.  It’s generally cheaper.  It’s also available immediately, rather than the months (or years) it takes to develop and debug a custom application.  The off-the-shelf software usually has pretty good technical support and a community behind it that can answer those tough questions.  The customer also knows it’s likely the company behind the commercial software will be still be in existence for many years.

Custom programming, on the other hand, is expensive and time consuming.  If the customer wants you to write a QuickBooks killer they’d better be prepared to wait a while and spend some serious money.  Creating software that competes with established, feature-rich applications is a daunting task.

I am sometimes amazed at the reactions from customers when I give them estimates.  Really!?  You thought writing a QuickBooks clone would take 3 months and only cost $10k?

Most contract developers don’t provide much technical support for the product they’ve developed, leaving it up to the customer to fend for themselves.  Some clients are technically savvy, but most aren’t.  Is the customer going to fix the code themselves?  It’s been our experience that even the few clients that know Xojo aren’t capable of changing any code other than the most trivial – otherwise they’d have written it themselves.

Clients that are selling the application commercially are sometimes unprepared to handle tech support and that’s a problem as well.  If they can’t answer basic tech support questions are they going to rely on you to answer those questions?  Are they paying you to do this?  We had one client that assumed we would be providing free tech support, forever.

Is your custom programming business going to stick around for the long-haul?  Will the customer be able to come to you in five years and have you update their application for Windows 7 or Mac OS XIII or the current flavor(s) of Linux?  The customer wants and needs long-term stability.  I good portion of our clients have come from Real Studio and Xojo developers that are no longer consulting.

With all the problems associated with custom programming, why should anyone spend the money on it at all?  The customer gets exactly what they asked for.  If they’ve done a good job explaining their requirements and you’ve done a good job implementing them, they have something that makes their business very effective, very efficient, and is tailored to their business model.

Custom software might be an asset to the client in the event they sell their business.  Some of this depends upon the contract details you signed (you do have a contract, right?) before you started the project.  A lot of clients are going to want some sort of clause that allows them the rights to sell the software (with source code) to another party.

Custom software allows for additions and changes to occur over time.  Off-the-shelf software may be cheap, but try getting Intuit to change the way QuickBooks does their payroll or the way they handle payments.  Custom software allows the customer to grow their software as their company grows.  If the customer wants to integrate CRM functions into their accounting application this year and add event scheduling next year they can.  It’s really only a matter of your time and their money.

When talking to a potential customer for custom programming, be honest.  Tell them the advantages of custom programming.  You also need to be honest about the negatives as well.  A big part of dealing with clients is managing their expectations on what you can and can’t do for them.

Thankfully, by the time a client gets to us they’ve already explored off-the-shelf solutions and have ruled them out.  Usually they have a very specific need that can’t be addressed with the one-size-fits-all commercial application.

Have you ever convinced a client to use off-the-shelf software rather than your custom written solution?  Other thoughts?

Differentiating Your Services

There are hundreds of consultants out there doing the exact same thing you do.  They’re hustling to sell their services to the very same people you’re trying to sell to.  They don’t live in New York city or San Francisco and can live on $15/hour.  How can you, a good developer, compete with overseas programmers or newbies?

Let’s be honest.  If the client is evaluating potential developers solely on price then you probably don’t want them as a client anyway.  That’s not to say that price should be ignored because a client that’s not frugal with their money is a problem too.  But, it is possible to win a bid even with a higher end price.

So how do you differentiate yourself from the cheap programmers?  The first thing to have is a page on your website that shows previous projects.  This shows potential clients the type of work you’ve done before.  You have to be careful about violating any Non-Disclosure Agreements you have, but for the most part you don’t have to get into specific details about a project to portray the type of work it was.

If you’re just starting out, your previous projects page is going to be sparse.  Another drawback is when your previous projects page doesn’t show the skills the client is looking for.  Unfortunately, the only way to get around this problem is to be upfront with the client and let them know you’ve done the research and have a plan.

Do you have off-site storage of source code?  If you’re working out of your house (who needs an office anyway?) you should probably have automatic backup of source code to an off-site facility.  In the event of a disaster like a flood, fire, earthquake or someone breaks into your house, this is a simple and inexpensive way to protect your work.

We use a Subversion host that gives us gigabytes of storage that amounts to hundreds of Xojo projects files along with documentation and other supplementary info.  The host itself has offsite backup storage and hourly backups.  Does this sound paranoid?  You bet it does!  Your code is your money maker and the client isn’t going to be willing to fund several more months worth of work because your hard drive crashed or your laptop was stolen and you have to recreate your work.  They don’t care, they just want the project done.

Bug tracking systems like Bugzilla, Mantis and many others are good open source software applications that make bug tracking cheap and easy.  Using a bug tracking system is light years ahead of working strictly through email, if for nothing more than the documentation features and audit trail features.  The client can log into the system and see a bug’s status and add additional information.  You, as the developer, can request additional information, close a bug, or merge it with another one.  A good bug tracking system is a must on large projects or projects with multiple developers.

Oddly enough, the other thing that can differentiate yourself from other developers is your contract (you do have a contract, right?).  A good contract is not only protection for you and your client legally, it is also a way to document what you will and won’t do.  It’s the first step into managing the expectations of the client.

Contracts can be a pain to create.  Start with a standard contract.  I’ve been pretty impressed with the documents at www.docracy.com.  Once you have one you like you can add to it.  We use a standard boilerplate contract that is fill-in-the-blank for the basics (name, address, etc) and has general responsibilities for us and the client.  We constantly refer to Appendix A that lists all of our deliverables (source code, installers, documentation, etc), client deliverables (graphics, timely testing, etc), a brief description of what the code will do, and the payment terms.

Price is important and you’ll lose some clients because of it.  It happens.  But using some of the tools and techniques we’ve talked about you can differentiate yourself from the cheap and inexperienced developers.

What things help differentiate you from other developers?