IDG Contributor Network: Facing the new build vs. buy problem in application delivery


The market for application components delivered in the cloud using a subscription model is exploding—it spans the and it is .

Given the high quality of these component services, it can be difficult to determine how to source your parts—should you use a supplier, or build it yourself? There are many different ways to cut this problem, but a valuable mental model that can help you make your decision is to look at code as a liability.

The natural inclination is to think of code as an asset to the business. It’s something you invest resources in to build, and it drives the growth of your business. But an alternate line of thinking looks at writing code as creating risk, as a necessary evil to create value for the business.

Similar to financial debt, the idea goes something like this: You take out a mortgage to buy a house, you only want the house, but not the mortgage. So you minimize the mortgage as much as possible, keeping it around only long enough to obtain the value (the house). And if you move to a new house, you don’t take the mortgage with you. The debt—the liability—is a means to value.

. If your processes are not clear, your application is still early stage, or you are contemplating major change in your application delivery systems, adding more code is probably taking on bad debt.

2. Cultural debt

Is it worth hurting your team to build a new module when you can buy it as a service? The second liability to consider is —this occurs when the benefits of your decision have long term impacts on the culture of your organization. It’s necessary to consider whether you are going to hurt your ability to deliver value if issues crop up across your most valuable resource: people. Disconnection, discontent, and uncertainty will abound when you cut people off from data, information, processes, or each other. Put your people first! Make sure you aren’t taking on cultural debt with your technical decisions.

with these specialties. They seem like very solvable problems, but the reality is that analytics is highly complex, and integrations can be tricky to set up and very difficult to maintain over time.

4. Vendor volatility

The final consideration is the vendor itself. Your vendors need to be evaluated carefully to ensure reliability of their services and conformance with your own legal and contractual obligations. Some key points include:

  • Certifications like ISO 27001 or SOC2 provide a easy shortcut to arrive at your decision on whether to trust the vendor’s technical chops. But if the vendor does not have them, you can do your own diligence to provide assurance.
  • For small or new companies, you should ask for references from other customers in the same segment as you. Ask for local customers, take them out to lunch, and get an idea about what it’s like to work with the vendor.
  • Ideally, pick vendors where you have the opportunity to work together, drive their product roadmap and develop features with them. See if you are able to have a relationship with their product managers to get a transparent view into how their service works.

It pays to work with your vendors and support their growth—it reduces the risk of creating a new dependency in your software supply chain. 


“Code as liability” thinking adds strategic value and provides a greater depth into planning the decisions your organization is making. It implies that you need to think twice before handing off work to the development team. Using a service to deliver a component that you don’t need to manage actually starts to look reasonable compared to the cost of maintaining it over time. The market for third-party code and application delivery services reflects this, so get out there and see how you can leverage the market opportunity.