Where are you going wrong when choosing to buy, not build?

Often when we are designing software we make the decision to buy, rather than to build. This means to integrate third-party software providers into your solution, rather than building the components yourself. Common examples include authentication, payment, and email, but there are many others.

When first designing a solution the decision around which provider to use can be difficult to tackle. At endjin we have developed a system for answering the question "which provider should I use?". The answer to this question varies massively depending on your requirements. These requirements are therefore placed at the centre of the evaluation.

1. Define your evaluation criteria

This is possibly the most important part of the process. In order to choose a provider that best suits your requirements, those requirements need to be well defined and measurable.

E.g. We recently did an evaluation of payment providers. Here were some of our criteria:

• SDKs / examples / documentation
• Previous experience / IP
• Recurring payments
• Customisation
• Audit / payment logs
• Maturity / dev support / technical support
• Cost / license
• Automation / DevOps / Testing

2. Pick your candidates

Now pick the candidate providers for evaluation. We usually have a range of 3-6 candidates. It is worth assessing at least three options, as it might give you some more understanding of the problem space in general. However, much more than six quickly becomes time-consuming and unwieldly.

It might be that there are a lot of options (there were with payment providers!), to narrow these down you can look at statistics of the most widely used, or perhaps start with a few which people on the team have experience with. There are also a lot of review sites online which can give you a quick overview of the providers which are most widely adopted.

However, these reviews are no substitute for the evaluation (though they might help when filling it out), as you will have specific requirements which you need to ensure will be met by any choice you make.

3. Assess each candidate

Then run through your evaluation criteria and make an assessment about each provider. This might look something like this:

Some of this information can be found via the company websites, some from reviews of the technology, and some from prior experience. It is useful in all these cases to include links to the sources of the information, which can be referred back to later.

4. Highlight the biggest risks

For each provider, highlight the areas which contain the largest risks/limitations. Assess whether any of these constitute a no-go decision. A key example of this might be the cost – some of the options may just be prohibitively expensive. But other areas, such as developer support, or testability, might be equally as important to consider.

5. Make a decision

With all the information gathered, it's decision time. This is done using a combination of no-go limitations, and prioritisation of the rest of your requirements.

In my experience, by the time that you reach this point you generally have quite a good idea of how the decision will go. But it is still important to do this part methodically, considering all the options and crucially the limitations/risk around each.

6. Record that decision

Finally, it is crucially important to record the decision made in an architectural decision record (ADR).

This should outline the problem, list the evaluation criteria and options, and call out the key drivers for the decision reached. The ADR will serve as evidence for the decision made and provide long-lived understanding and insight for future teams working on the system.