Contract software developers have to deal with a lot of issues, especially if they are honest. There are loads of scam artists out there who can’t code particularly well, but will throw an application together for a client quickly, often disappearing shortly afterward. I’ve cleaned up lots of code from that sort and it’s a headache. This article wasn’t really written for that sort of developer, however, as I believe it’s very easy to accidentally screw a client over, even when one is otherwise trustworthy and honest, simply because you don’t think through all the implications of what you are doing. Here are ten ways I’ve seen developers screw their clients, without intending to do so. This is aimed more at solo developers, although a number of these points could apply to larger companies as well.

1. Not considering business continuity. This one actually came up for me fairly recently while discussing building a fair-sized project for a client. While certain critical business applications can still be built by a single developer, one should remember that we all die. Never, ever, create a situation where if you get hit by a bus that your client’s business goes under because a critical piece of infrastructure is dependent on you and only you. Besides the fact that in some cases this could result in your estate (ie., your wife and kids) getting sued to recover damages, it can also ruin a vacation for you even if you don’t die. Someone else should have the means to troubleshoot critical business infrastructure if you aren’t around, whether you are in a box or in the Bahamas. It’s very easy for a developer who is their own sales team, web designer, network admin, and project manager to forget this rule.
2. Failing to keep sensitive data off of developer systems. When working with client data, it’s a lot easier to just get a copy of a production database and simply run with it. There is, however, substantial danger here. Sensitive data is a risk as long as it lives on your system. If you get hacked, your client can easily incur more damage from the hack than the combined value of all of your assets (for instance, if there is a breach of private health information, credit card or other information useful to identity thieves, or secret formulas). If you are a solo developer and don’t want to go to the trouble of having a locked server room somewhere with controlled access, you should not have sensitive client data on your system. Scrub the data before accepting it. Sure, it takes more time, but rendering the database useless in the event of a breach is the best way to keep the client and yourself safe.
3. Not adequately preparing the client for ongoing maintenance costs. Developers like to try to choose the best tools for the job, but it’s very easy, in the excitement of starting a new project, to forget to consider what the application is going to cost to run. I’ve found this to be especially true for various libraries, and for reporting and database solutions. Just because it is the best tool for the job in the absence of monetary considerations does not make it the best tool for the job when money is in the mix. You should be especially cautious of things like software licenses that are free for non-commercial use, as some of them have rather high price tags if you are using them in the context of a business. You should also consider the total cost of ownership of running the software in question. How much does it cost to get a capable administrator to handle patching, backups, and updates for the software? You should be asking these questions before choosing components for your application.
4. Not preparing (and documenting) application deployment procedures. Deployment is an area developers frequently ignore until the end of a project. This is short-sighted and foolish, but everybody does it for quite a while until it becomes apparently how profoundly bad of an idea it is. Your application deployment procedures should be cleanly documented and/or automated for any number of reasons. The first is that it helps lead to a successful project rollout, but more important on an ongoing basis is that it allows your client to smoothly move the software to another machine without requiring your involvement. If you want to go on vacation or expect to eventually die, it’s important for your client to be capable of doing this themselves, or for a reasonably competent tech to be able to do it for them without spending a large amount of time.
5. Inaccuracy in project estimation. Another place I see small development shops frequently having problems is in the realm of providing proper and accurate estimates on projects, particularly when the project is billed at an hourly rate. This immediately hurts the client and can cause significant angst for both the developer and the business owner for whom they are working. Your client may have a very tight budget and not have much slack in it. You must make absolutely certain when estimating to get a full scope of work, so that you can come up with a reasonably accurate estimate. The business owner is likely weighing the potential cost of your help against the benefits, and an inaccurate estimate can cause them to make decisions that are not in their best interest, possibly even causing them to go out of business in the extreme case. It’s easy for developers to give bad estimates, because nearly all of us are overly optimistic about how long a project will take to complete. Don’t fall into the trap.
6. Failing to get end users involved in a project early on. Typically when you land a new project, the person paying for your work is not the same person who uses the application daily. While the person paying may feel that they know exactly what is required, it’s actually fairly unlikely if they aren’t using the application every day. End users may have lots of suggestions for improving or replacing an application with something else. It’s also important to get end users involved in scoping out a project early in order to get buy-in from those users. If you fail to do this, it’s very easy to ship an application that doesn’t meet the actual needs of the users and is actively resisted by them (because it feels like a change imposed on them from management). You should tell the client early on that you prefer to have some contact with a smart end-user in order to avoid these problems (and to help make sure the client is successful).
7. Incorrect prioritization of project features. This dovetails with the item above. You should work closely with the client to make sure that the most important features are prioritized. Oftentimes, projects get underway and have to be put on hold or have their scope reduced because of financial or other concerns. Taking the time to properly prioritize the features required by the client and working on the most important ones first will allow you to still more easily deliver something of value, even if the project is put on hold. Particularly in cases where financial issues are the cause of a project being paused, delivering something that saves the client money (or makes them money) can help alleviate the problem more quickly and get the project back on schedule. At the very least, the client won’t be saddled with a bill and a product full of features that are low priority.
8. Inadequate audit trails. Audit trails are one of the last things a lot of people think about. I know I’m particularly susceptible to this and most other developers I know have the same problem. Clients can be relied upon (unless they are dealing with medical or financial records) to never think about this until something happens. You should always build in at least a rudimentary level of audit trailing into your applications, both to help you diagnose problems, and to pull the client’s bacon off the fire when something happens with one of their systems. Some percentage of employees will steal or simply be incompetent and good audit trails are one of the best ways to determine that. If something costs money in your system, you should absolutely track it. Adequate audit trails also help protect you from the accusation of producing broken software when employee training issues are the actual culprit. Or if it is your software that is broken, a good audit trail will help you debug, so that you can quickly fix it.
9. Inadequate reporting of stability events. Another area in which many developers fall down is poor handling of error conditions in an application. If your application is generating an error, it needs to notify someone. The client’s support staff should not be getting blindsided with users calling in to say that they can’t access something that is business critical. If you give them a head start (and appropriate diagnostic information), it can save them from major problems and possibly help prevent business-damaging actions being taken to avoid whatever weird bug your application creates whenever an error occurs and is hidden.
10. Inadequate abstraction of external APIs. Frequently, projects for clients involve integrating with some third-party platform. Whether it’s Facebook for logins, Amazon for affiliate marketing, or other services for sending email and the like, you need to be sure and abstract any connection between your client’s app and the outside world. Make it less painful to change the third party connection to something in the future to the degree possible. This allows businesses to be more flexible with their partner arrangements and can help avoid grinding everything to a halt when a third party site is offline. You can’t always do this (for instance, if facebook is down and you use them for logins, you are pretty much hosed), but a bit of paranoid programming around API integration points can really protect your client from problems.

You may have noticed a couple of patterns in my above suggestions. Largely, the advice is centered around tolerating failure, being predictable and transparent, and being considerate of your client’s finances. If you’re honest and do good work, just carefully considering what sort of situation you are leaving a client in can help considerably in making sure that they aren’t stuck in a bad position because of something you did. It isn’t rocket science (don’t take advice regarding rocket science from random bloggers on the internet, by the way), but it’s easy to forget. A little bit of caution can save someone thousands of dollars down the road and possibly avoid bankruptcy for both you and them.