Are You In or Out? (of the Box); Optimizing Software Buy vs. Build Decisions

Peter Aten
4 min readMay 18, 2023

--

Every software program is a gift box. Inside the box are the capabilities the software offers, the cool things that users can do to be more creative, innovative, efficient, accurate, etc. The sides of the box represent constraints because no software can solve every problem for everyone. All software is designed to address a certain set of needs, in a certain way, and thus every box is unique with its own set of dimensions.

Organizations are often faced with the decision of whether to buy or build a software solution. I think this metaphor is useful in evaluating that choice and helping organizations to scale their capabilities effectively.

When you decide to build custom software, you get to design the box. You have the opportunity to get exactly the set of capabilities that you’re looking for, and a set of constraints that you agree you can live with, all without having to pay an annual licensing fee to a 3rd party vendor. The lead time required to define system requirements and build the solution, as well as the associated opportunity costs, are the obvious impediments to this approach.

When you consider buying a vendor’s software, someone else has designed the box. It has a set of both capabilities and constraints that almost certainly differ from your ideal state. It is designed to satisfy the requirements of many different customers, so is likely highly configurable but also perhaps compromised. But it is also built and ready to be configured/used, providing you with a faster path to value. You’re considering it because you can live with those trade-offs.

What I will argue below is that if you decide to buy a vendor solution, you have to be satisfied staying within the confines of the box that you are buying. Buying a vendor’s box and then investing in significantly altering the box has significant downsides.

Vendors commonly describe their enterprise solutions as low-code or no-code. These have become industry buzzwords, extoling citizen-developer possibilities. A reality check reveals:

  • Every vendor solution is low-code or no-code; they’ve already written all the core code, otherwise why would you be buying it?
  • “No-code” means that the product is highly configurable, which totally makes sense. It must satisfy the differing requirements of a multitude of customers. But understanding how to configure a vendor enterprise solution requires an expertise in that solution, so casual users will not be the ones performing that configuration. You will need to develop deep knowledge of the vendor solution within your organization, a new expense in addition to the software itself.
  • “Low-code” means that you can have your team write custom code to enhance the configured vendor solution, but at the risk that your code won’t be compliant with a future vendor upgrade. The more code that your organization writes to enhance a vendor solution the greater the potential downside.

What I particularly want to discourage is asking the vendor to significantly alter the box for your custom needs. If your needs align with what the vendor perceives as market trends then the product is likely to evolve in your favor but if the vendor is charging you for updates, and worse yet releasing those updates in a custom-to-you branch, that is a warning sign. Satisfying specific-to-you requirements distracts the vendor from executing on their product roadmap so they’re unlikely to stay committed to your needs indefinitely. In addition, once you are sufficiently dependent on this semi-custom solution the vendor knows that your options to change course are very limited and that’s likely to show up as increased costs at renewal.

Other considerations include the following:

  • Depending on the license terms and the size of your organization, vendor software may have a much higher long-term cost of ownership than custom software. 3rd party software typically has lower up-front costs offset by an ongoing annual license expense based on headcount or other metrics, and often a one-time implementation cost as well. Custom software typically has a higher up-front cost which can be partially offset by capitalizing and depreciating the expense over time, plus some level of ongoing maintenance and support. Do the math to understand the Total Cost of Ownership for your situation.
  • With vendor software you are at the mercy of the vendor’s roadmap, rather than being able to dictate priorities yourself. If the existing vendor box meets your needs this may not be a significant consideration.

Conclusion

I think it generally makes sense to buy to accelerate and build to differentiate. When considering buying a vendor’s software solution, evaluate how willing you are to stay inside the box that the vendor has defined, as well as other hidden costs of bringing a new technology into your organization. When trade-offs allow build custom software where it can lower TCO and/or be a differentiator for your business, what Domain Driven Design would refer to as a core domain, where a tailored solution is likely to have the greatest positive impact.

--

--

Peter Aten

Interested in making great software, and particularly in how to make teams more effective