Client app updates...what is the proper way to deal with them?

Question

I do a lot of freelance work and clients often have me build apps from existing packages and applications (i.e.: Wordpress, Magento, Firefox [extensions] etc.). Six or seven months down the line, an update is usually available for the package which I built the apps from. With Wordpress, it's likely that it's a security update; sometimes it's a security update that's gotten rolled up into new code that's not compatible with a lot of old code (Wordpress 2.5, anybody?). Firefox breaks all of their existing extensions with every major update.

Now my question is whether it is professional to be charging standard rates to clients to deal with these updates. Sure, some of them require back-end updates (when the package is not inherently backward-compatible with existing code) but a lot of the time it's simply a migration thing: backing up files, copying, copying new files in, testing, etc.

I've recently had a client demand that I update his app to the latest version of it's parent application at no charge because I "chose a buggy application to build off of". In the past, I've had clients that have told me that I "should have planned for future updates". Has anybody else experienced this? How does the rest of the world deal with this?

Answer 1

The obvious answer is to always explicitly lay out your future obligations to the client in the initial contract. Most customers I've dealt with over the years are used to their custom software eventually not working on modern equipment anymore. I can't count the number of DOS or VB6 apps I've replaced over the years because the client's one old machine that still ran them finally broke down. As long as you make it clear to clients upfront that they will have to pay for support from time to time in the future, they should be OK with it all. And if they're not OK with it, you usually have the upper hand anyway. No rational client will pay to have their software rewritten so that don't have to pay you to support it anymore.

I've written mostly in .Net for the last 10 years, so this problem rarely comes up for me. Backwards compatibility is one thing Microsoft is undeniably good at.

Answer 2

The short answer is to manage expectations before you start the project: "no surprises"

A key point to discuss with clients is life cycle costs or whole-life costs. For software projects with a service life of several years the initial up front costs to build the application is approximately one-tenth of the total cost added up over the life of the application.

As for being responsible for bugs in a "buggy application" that you selected, well that should be addressed in the contract before you start. The decision as to what application (Wordpress, PHP, MySql or whatever) to use for a project should be a joint decision with the client, not yours alone. If the client requires that all future bugs be fixed then perhaps a service contract from the vendor should be obtained.

Large firms will offer service level agreements, and if you contract for premium hosting services you can get them.

Of course all of this comes at a price. AN Oracle database with a service contract costs much more that a "free" open source database.

Now if a client discusses these items with you and wishes to use open source for example, then the contract should specify that any updates or maintenance should be at time and materials.

Is it professional and reasonable to charge for work done after initial delivery? Absolutely! as long as it is disclosed up front.