Rules for custom software

  1. Custom software should enable your core business. There are countless software packages on the market serving common business functions. It makes no sense to invest in expensive custom software if it is not driving your bottom line. Successful custom software projects will enable your business to do more of what it does best. A consultant should help you evaluate where using custom software makes sense and offer off-the-shelf alternatives if an appropriate solution already exists.
  2. Custom software pays for itself. You should be able to quantify your expected ROI before signing a development contract. In some cases this is easy to do: software that increases throughput, helps win additional business, or directly generates revenue in some other way can easily prove it’s worth. In some cases the payoff of software is less visible: reduction of employee time spent on overhead tasks, elimination of human error, or even increased employee morale can all result from better software. I believe a successful project should deliver at least 3X ROI in the first year after implementation.
  3. If you’re being charged by the hour, run like hell. There is an Ed Kless quote I really like: “If you aren’t good at what you do, charge by the hour.” A qualified developer who is genuinely interested in your business’s success will take the time to understand your situation, identify potential roadblocks, and design an effective solution that fits your budget. Based on their past experience they will be able to provide an accurate quote or fixed price agreement for the project.
  4. Custom software requires maintenance. Just like Microsoft regularly releases updates to Windows and Office, custom software also requires periodic care to address bug fixes, changes in business processes, and changes in 3rd party APIs. As part of a development contract, your software provider should provide a retainer to address issues such as bug fixes or user support questions. Information about future maintenance costs should be included as part of buyer education before you sign a contract.
  5. Custom software should be agile. It’s all too common that a consultant shows up, listens to your problems, and then disappears for months to code up a solution. When they return, it’s inevitable that somewhere there was a miscommunication and the software does not exactly fit your business. Efforts to modify the software result in expensive change orders. A reputable consultant should engage the buyer and end users regularly during the development cycle to discover misunderstandings as quickly as possible. Minor changes which do not affect the development schedule should not incur additional cost.