Buy vs. Build: The Software Decision That’s Less About Magic and More About Logic

Good Intentions

One of my so-called “good intentions” at the beginning of this year was to start writing a book on the role of a software architect. So far, I’ve managed to create a table of contents. Since time management is one of the topics to be covered, I guess I’d better work on improving my own time management skills before diving into writing a book.

In the meantime, I’ve decided to at least start by posting a few blog entries. So here we go.

A Passion for Building

One of the first topics I’d like to explore is the ever-recurring "buy vs. build" debate in IT.

Those who know me personally are aware of my passion for building—not just IT software, but actual construction. For the past decade, I’ve been immersed in building our family house and everything that comes with it. From this hands-on experience, I’ve learned that:

• Building takes time (apparently, spending ten years on constructing your house is considered excessive).
• There’s a risk of rework as new insights emerge throughout the process (was a complete kitchen remodel after a few years really the best decision?).
• It involves countless choices and options (from selecting windows and bricks to deciding on ventilation and heating systems).

However, inspired by the 1996 movie Trainspotting, you might choose not to choose. Instead of building, you can opt for something already completed. In other words, you can choose to buy a finished house—one that arrives ready-made, allowing you to move in faster, but requiring you to adapt to its existing design and features.

Old Problems Resurfacing in the Digital Age

In IT, we often face similar questions: should we build a custom solution tailored to our specific needs, accepting that it will take longer, require more investment, and involve numerous choices along the way? Or should we buy an existing product that can be deployed much faster, while conforming to its predefined ways of working?

Unfortunately (or rather fortunately?), this isn’t solely an IT decision but a strategic organisational one. As Gregor Hohpe discusses in this article, organisations have traditionally relied on the heuristic:

“If the functionality differentiates you, build the solution in-house; otherwise, purchase commercial off-the-shelf software.”

It sounds straightforward, but this IT decision just became a broader business decision. Business leaders should determine which functionalities are critical for differentiation, and IT can then make decisions based on that direction.

Capturing Business Processes: The Pokémon Approach

Capturing business processes is often more complex than it seems. Frequently, understanding the business leads to debates about how the soon-to-be-replaced system functions rather than focusing on how the actual business processes work—or even more challenging, how the business wants to operate in the future. Getting to the core of the business processes can be difficult, even for those within the organisation, and requires moving beyond the implementation and interpretation of existing IT systems.

So, how do you uncover your true business processes? Just as Pokémon trainers capture and collect different Pokémon, the "Pokémon approach" means capturing and understanding the essential elements of business processes. A valuable exercise is to imagine a world without computers (ah, nostalgia) and ask questions like, “How would you handle this on paper?” Combining this approach with techniques such as event storming and role playing can provide very valuable insights into the real business events and processes. Once you have a clear understanding, you can then consider how to differentiate based on strategic organisational decisions and future visions. It’s all about taking a step back to take several steps forward.

And...when talking about differentiation this doesn’t necessarily mean doing things differently from competitors. For instance, in a government context where competition isn't a factor, leveraging IT to automate tailored processes can still be valuable — by reducing employee workload and improving communication with citizens, partners, suppliers, and other stakeholders.

In other words, start by mapping out your business processes. Identify which parts are strategically important for the near future. These are the areas where you need maximum flexibility, both business-wise and IT-wise. Typically, these are the aspects you would choose to build in-house to align with your strategic goals.

1 + 1 = 3

To actually put this in practice I find the intersection of Domain-Driven Design (DDD) and Wardley Maps, as explored by Susanne Kaiser, particularly insightful. In her talk, Susanne effectively integrates strategic DDD domains with Wardley Maps, linking them to business strategy. This approach visually connects your buy vs. build decisions with your business operations in a compelling way.

For businesses, making informed buy vs. build choices is crucial. As Simon Sinek highlights, most businesses are engaged in what he terms the "infinite game." Unlike finite games—such as football or chess, which have fixed rules and clear endpoints—infinite games like business, politics, or life itself are ongoing. In these games, players come and go, rules evolve, and there is no definitive end. Success in an infinite game is not about winning or losing but about staying ahead or falling behind.

To thrive long-term, businesses must adopt an infinite mindset. A key concept in Sinek’s framework is "Existential Flexibility"—the ability to adapt and change rather than committing to a single solution. In today’s digital age, being open to change is essential for survival. Investing in core business domains and designing them for adaptability is crucial for long-term success. Simultaneously, focusing less on areas where there is no competitive advantage helps avoid expending unnecessary effort on non-strategic elements.

Susanne's approach captures the very essence of this in a highly understandable model, applicable to both business and IT

Buy Right or Customize Wrong

Which brings me to my final point: If your organisation decides to purchase software, make sure you choose the right product. I often see a trend where businesses buy a software solution and then begin customising it extensively to fit their needs. A common example is purchasing a CRM system with a multitude of plugins, low or no-code support for flexibility, and a rule engine designed to handle every conceivable business scenario (what about that Silver Bullet?). While these features do offer extensive customisation, they often lead to long-term maintenance issues, commonly referred to as "upgrade hell."

To avoid this, refrain from heavily customising off-the-shelf solutions. When evaluating a product, I recommend visiting the product's website and start by simply assessing whether the terminology and product core objectives align with your business needs. If the language of the product feels unfamiliar or if its primary goals don't match your business requirements, don’t fall into the trap of buying and then extensively customising it. Instead, choose a product that already aligns with your needs to minimise future complications.