5 questions for vetting 3rd-party software choices

A development team usually tells their client about the tools they have chosen for a web project during the proposal or design phase, so it's usually with at least a pinch of sales-pitchy enthusiasm. It's understandable that developers want to project confidence, but exaggerated certainty is a common culprit when it comes to poor software decisions. Clients and developers alike should embrace the idea that indecisiveness is not a sign incompetence, and challenging a recommendation is not a sign of lack of faith in the developer. Poor software choices can be very costly for companies who get taken down the wrong path. It's worth asking the tough questions early on.

But clients may have difficulty knowing what tough questions to ask. Besides knowing to inquire about the software's capabilities, maintenance costs, and vendor support, many companies don't have people on staff who can really assess the technology under the hood. In that spirit, I have put together a series of questions below that can be used by both developers and clients during the software vetting process.

Let me disclaim that there is no magical formula for making pain-free software decisions. Sometimes the answer is a no-brainer, but sometimes it requires debate, research, and testing. Plus, there rarely is one "right" answer. You can give two of the most experienced, reputable, big-brained system architects the same problem to solve and chances are they will choose different avenues. A lot of it is a matter of coding style and personal preference.

But the "there is no right answer" argument can also be a cop-out, because we all know that some choices are clearly better then others. With that, here are the questions:

1. How far will the out-of-box functionality get you, and how hard will that last mile be?
   Some solutions will get you 90 percent there, but, man-ah-man, that last 10 percent will be a grind - adding custom-development hours and complex code to the project. Some products offer a great framework for extending the code. Some require coders to get hacky, making future upgrades and updates a potential source of problems.
2. Is the customization worth it? Is there a different, simpler way, using way pre-built tools?
   Sometimes a turn-key software package offers solutions that are different than the way the client and developer originally envisioned things. It's worth keeping an open mind about alternate approaches where off-the-shelf might do the job as is. Not only may they be cheaper and easier to maintain, there may be good technical or operational reasons behind the different workflow that are not obvious in the first stages of planning.
3. What will the vendor support be like tomorrow, next year, and beyond?
   We are fans and long-time users of open-source community-based software projects, but sometimes free products give you exactly what you pay for. It's not uncommon that open-source products start out with a community-focus on free software, only to end up concentrating maintenance and support only in the for-profit areas of their business, leaving the open-source users feeling neglected and confused.
4. Has the development team used this software before? Was it picked specifically for the job?
   If a development team is not very experienced with a software package, that can be a source of additional costs. Developers can offer the best price and delivery timeline when working in their element. On the other hand, if a team always uses the same product for their projects, they could be steering away from a more suitable solution for your business. Developers often get comfortable with certain tools and end up choosing them - not necessary because they are the right tools for the job, but because they are just set in their ways.
5. What are the hidden costs of the software?
   Usability makes a big difference in the operating costs of software. If your web tool requires employees to click unnecessarily several times per action, and load multiple pages to perform one task, wasted time and frustration will accumulate. This is often the case when open-source CMSs are forced via a series of plug-ins to do tasks outside their design scope. User-experience design at the start of a project will mitigate these hidden costs by tailoring an application that functions precisely as your business and employees work.