Software: Build or buy? The right answer could deliver better value to your business

Should we build or buy? That is a question asked often, and I think the answer is clear: It depends. Are you a software company? If so, building software solutions is probably in your DNA. But even software companies buy software, so why is that? Do they not have the industry expertise or resources? Or are they focusing their resources on building the products that their customers require so they can remain competitive? Most of us are not in the business of building software—we do other things. In my last role, I was the CIO for the Nevada Department of Transportation, where our primary function was to build safe and efficient highway infrastructure, not software. Did we write software? Yes. Was that the best use of our time and resources? Probably not. Then why did we do it?

Early in my career, organizations got into application development because it was necessary. Many applications were very industry-specific, and commercially available software primarily focused on office productivity. If you wanted something tailored to your specific industry or business case, you had to either write it yourself or pay a third party to write it for you. Many of these applications required significant human intervention to keep them running, monitor jobs, and keep the source code current, in addition to maintaining the backend database, application, web, reporting servers, etc.

These applications also needed to be updated regularly to minimize security risks. Unfortunately, upgrades were painful, and the next operating system upgrade or security patch could completely break the application. Because of the amount of work required to update and test applications, many organizations would forgo or delay these upgrades, putting their organization at risk.

About ten years ago, a vendor I had been doing business with for several years gave me access to a product his company was developing. Over the years that we had worked together, we developed a great working relationship and a lot of trust and respect for each other. When I opened the link he had sent me, I just looked at it and said, “I don’t get it. What is this, and what is it supposed to do?”

He laughed and said, “Anything you want it to do.”

I still did not get it. It was like looking at a blank piece of canvas and being told that I could paint anything I wanted on it. I guess I am not much of an artist. He explained some of the basics: With the right permissions, I could, for example, add my own fields, adjust the page layout, create my own workflows and reports, and set up notifications without having to write any code myself. This was an eye-opening experience and helped me understand what a highly configurable product was.

Back then, many companies said they had configurable products, but behind the scenes, they were a mix of configurations and customizations. Still, this was a vast improvement over the completely custom-written applications we had been using. A few years later, we were using that product for two distinct business cases. That product has continued to grow and change as business needs have changed over the years. This experience made me think about our future in application development and where the industry is headed.

I now understand how these highly configurable products could help us deliver more business value. Rather than having team members dedicated to maintaining applications and essentially the status quo, we could now focus on delivering more value to our customers by partnering with vendors that create and host these highly configurable solutions. 

Over time, we transitioned most of our application development positions to other roles that added greater business value for our organization. I used to use the analogy of building a car. I have most of the tools and technology to build my own car, but should I? What will it cost in the long run? How much time is it going to take? How well will it run compared to a car I could buy? Who is going to maintain it? Think about the infrastructure it takes to design and build a car—the same expertise and resource allocation are required to build and maintain quality software solutions. 

Properly built, highly configurable applications allow the vendors to release new features and keep the underlying systems patched and maintained without significant downtime or impact on the business. 

You can also begin to empower the business, shift product ownership, and move the decision of when and what features to implement from IT to the business. Of course, some small point-type solutions will still be needed for one-off business cases that need to be addressed. For those, I would recommend looking into some of the no-code and low-code tools that are becoming readily available. This is another opportunity to extend conventional capabilities to the experts and to focus on true enterprise solutions. With proper training and governance, a line of business users can create these solutions without needing traditional application development teams, tools, and training from IT. 

In conclusion, I recommend partnering with a company like Aurigo, an industry expert that focuses on highly configurable solutions. Look for products, such as Aurigo Masterworks, that are hosted in the cloud, scalable, and can grow with your business or agency. Look for vendors committed to continual investments in their solutions. Partnering with such a company for your software solutions lets you grow your team’s size and expertise without having to add headcount. This frees up your existing team members to focus on activities that will bring the most value to your organization and the people you serve.