The decision to buy or build

The single biggest factor in this decision is the availability, suitability and cost of commercially offered products. Our decision is the most straightforward when there is a commercially available product that meets our specific needs and is available at a price that we consider reasonable, especially when compared to the full life cycle costs to internally develop an alternative.

It’s even better when the product has been developed by one of our core software partners, for example our existing EHR or ERP vendors. In this situation we benefit from working with a trusted partner, and the solution will likely integrate smoothly into our existing workflows.

But often our decision is not so straightforward. The more unique our needs are, the more likely that a commercial solution will not meet those needs.

For example, for the patient care aspects of our work there tend to be more commercial products available to us compared to the offerings that might serve our school of medicine. For situations where there is no commercially available product, the decision comes down to “build or don’t build,” in which we decide to proceed or not based on assessing the ROI of the effort.

In situations where commercially available products do exist, we will often issue an RFP and assess the vendor products, their features, and their cost as compared to an internally developed option.
Building internally – now what?

We’ve assessed our options and have decided that the best approach is to build and maintain a custom application. Clearly, we have a lot of work to do to develop a custom application, primarily the classic work of requirements, design, build and test. But what is often not appreciated is the amount of nontechnical work needed to build and support a custom application throughout its life cycle.

When you purchase a vendor product, you are purchasing more than just software. Commercial vendors continually update their products, which involves making decisions about which new features to introduce to improve the product. While customers may not agree with those decisions, that is work that does not need to be done internally. When a solution is developed internally, someone needs to perform the product management function of deciding what to build next from what becomes an increasingly lengthy list of “wish list” items from the internal user community.

Leave a Comment