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.

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.

The best hour you can spend to refine your own data strategy and leverage the latest capabilities on Azure to accelerate your road map.

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).

Programming C# 10 Book, by Ian Griffiths, published by O'Reilly Media, is now available to buy.

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, LinkedIn Learning instructor and STEM ambassador.

Over the past four years she has been focused on delivering cloud-first solutions to a variety of problems. These have ranged from highly-performant serverless architectures, to web applications, to reporting and insight pipelines and data analytics engines.

In her time at endjin, she has written many blog posts covering a huge range of topics, including deconstructing Rx operators and mental well-being and managing remote working.

Carmel's first LinkedIn Learning course on how to prepare for the Az-204 exam - developing solutions for Microsoft Azure - was released in April 2021. Over the last couple of years she has also spoken at NDC, APISpecs and SQLBits. These talks covered a range of topics, from reactive big-data processing to secure Azure architectures.

She is also passionate about diversity and inclusivity in tech. She is a STEM ambassador in her local community and is 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.

Carmel worked at endjin from 2016 to 2021.