And age-old question that is not really possible to settle. Should we the company build it? Or should we buy it? In general, I have a short set of questions that help to determine if it should be built, or if it should be bought:

1. Is the solution that is required, core to how you, or the business delivers value to your clients and consumers? Or is it an auxiliary/addendum that ensures that the business runs?
2. Is there an existing product that does what you need? Or one that you are already using that could be customised?
3. Do you have the resources to maintain the solution? Do you have the resources to build the solution? (in that order).
4. What are the costs of building and maintaining vs buying or customising?
5. Is the problem actually understood?
6. Are the goal posts well grounded?
7. Are the stakeholders engaged?

To expand on each of these as they can become nuanced.

1. Core Business Value before answering this, you need to know what you do, and what is the value that your clients get from you. It is easy to mistake a core function of the business (sending invoices, timesheets, project management) with the value that your customers and consumers get from your business. You may produce widgets, or you may provide knowledge-based services, but knowing what your customers and consumers actually value from you will aid in determining this.

In most organisations, administration, and management tools are not the core value that are being sought by customers and consumers. To help clarify, additional follow-on questions that should be asked include:

• Would building this provide greater value to your clients or consumers there by allowing you to charge more?
• Could this greatly reduce expenses or costs by a margin that is more significant than the cost to build and maintain?
• Will this allow you to have a competitive edge against your competitors?

2. Existing Products this usually is in the form of understanding the problem well enough to be able to search for the potential existing solutions. One key consideration I have come across numerous times is that it is very easy to think of your specific problem as being unique to your situation, and it is therefore you need to build. But this bias makes it difficult to determine the best key words to find a potential solution because you are using internal jargon, or language to search. This comes about in particular when the solution seems to be particularly well defined, but not the problem.

• What other ways can the problem be described?
• Do any of our existing solutions have the ability to provide this solution?
• How much flexibility does an existing product have (stated flexibility) vs how much flexibility will an internally built one actually have?

3. Resources for Maintenance and Build is easily one of the most overlooked aspects. Whilst the building of the solution may seem to be straight forward and can be identified, the long-term maintenance of the solution is where the resources can really be sucked into a pit. The maintenance of modern applications requires that you keep up to date with security, as well as the platforms underneath your application changing, APIs being modified.

At a minimum, a budget to maintain the upkeep of your system is required.

• If we build, and this becomes a central to our business. Do we have the resources to maintain it?
• If we buy it, and this becomes central to our business. Are there support contacts in place to maintain it?

4. Costs associated with the overall solution have some hidden areas that need to be explored. Generally, the buy option has very clear ongoing costs, less clear are onboarding costs but usually the supplier can assist on this. The buy option is the clearest and straight forward to understand and estimate.

When considering the build option, a lot of time is usually spent considering the build costs, but these are still going to be estimates. The area that is usually forgotten is the ongoing maintenance costs. When building and then hosting it, more consideration should be given to the associated costs of running and maintaining. Maintaining the uptime, fixing bugs, the costs for rectifying data issues that the bugs cause, managing the API changes with other applications that interact with yours, security updated and upgrades, stakeholder feedback, and everything else that is part of the maintaining a system.

Also to consider is the opportunity costs to a delay in the implementation, when speed is of the essence, buying is usually the best option. But that may also setup a hybrid option, buy now to fill the gap, and then move to the build option over time.

• What is the Total Cost of Ownership (TCO)?
  • What is the payback period of the capital component of the project?
• What is the ongoing maintenance for a build option?
• What is the ongoing support for a buy option?

5. Problem space is distinct to the solution space. Often, the solution is sought before the problem is fully understood. It’s crucial to understand the problem thoroughly before jumping to a solution. This involves asking questions, gathering data, and analysing the situation from multiple perspectives.

Once the problem space is understood, you can then evaluate if any of your existing systems can provide a satisfactory solution, or if any of them can be extended to provide a more complete solution. Ways to help you determine if you understand the problem space include:

• Can the problem be communicated to someone else, and they could create a solution?
• Why is this important to solve?
• Are there constraints to shape the solution?

6. Sucess Criteria by ensuring that the goal posts are well grounded. This means that the success criteria for the solution is clearly defined and agreed upon by key stakeholders. These criteria will guide the development process and provide a benchmark against which the solution can be evaluated to either be built or bought.

• Are the goal posts flexible enough to allow multiple possible solutions?
• Do the stakeholders have the same understanding of the success criteria?

7. Stakeholder Engagement can make or break any build vs buy project. Key stakeholders can significantly sway the decision. This could be due to strategic reasons or because the project is a pet project of a particular stakeholder. It’s essential to engage with stakeholders early and often to understand their needs, expectations, and concerns. Their input can provide valuable insights that can shape the solution.

• Are the stakeholders¹ known?
• Are the stakeholders actually engaging in the process?

With all of this in mind, there are some common areas that I see clients wanting to build, when they should probably buy include:

• Timesheet systems.
• Customer/Client Relationship Managers (CRMs).
• Bespoke file management systems.
• Human resource systems.
• Authentication systems.

Common areas that I see clients wanting to buy when they should strongly consider building instead:

• Core business processes that deliver value to clients.
• When you would need to divulge a lot of intellectual property, or trade secrets in order for the system to be implemented.

The decision to build or buy almost always results in a project and should not be taken lightly. It requires careful consideration of various factors, including the ones mentioned above. Ultimately, the goal is to choose the option that best supports your business objectives and provides the most value to your customers and consumers.

1. A stakeholder is anyone, or organisation who is impacted, interested, part of, or believes that they are part of the project. ↩︎