Skip to content
Carmel Eve By Carmel Eve Software Engineer I
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.

The Introduction to Rx.NET 2nd Edition (2024) Book, by Ian Griffiths & Lee Campbell, is now available to download for FREE.

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.

Discover your Power BI Maturity Score by taking our FREE 5 minute quiz.

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.

Carmel Eve

Software Engineer I

Carmel Eve

Carmel is a software engineer and LinkedIn Learning instructor. She worked at endjin from 2016 to 2021, focused on delivering cloud-first solutions to a variety of problems. These included highly performant serverless architectures, web applications, reporting and insight pipelines, and data analytics engines. After a three-year career break spent travelling around the world, she rejoined endjin in 2024.

Carmel has written many blog posts covering a huge range of topics, including deconstructing Rx operators, agile estimation and planning and mental well-being and managing remote working.

Carmel has released two courses on LinkedIn Learning - one on the Az-204 exam (developing solutions for Microsoft Azure) and one on Azure Data Lake. She has also spoken at NDC, APISpecs, and SQLBits, covering a range of topics from reactive big-data processing to secure Azure architectures.

She is passionate about diversity and inclusivity in tech. She spent two years as a STEM ambassador in her local community and taking part in a local mentorship scheme. Through this work she hopes to be a part of positive change in the industry.

Carmel won "Apprentice Engineer of the Year" at the Computing Rising Star Awards 2019.