Make APIs the #1 Requirement for Any Software You Buy

When I evaluate software for a customer, my first criterion has nothing to do with the software's functionality. My top requirement is a well-documented, publicly testable API that provides access to all the software's features.

I prioritise this check for two reasons. First, it's easy to test since it doesn't require vendor interaction and takes little time. Second, it's the requirement most often failed, so placing it at the start of the selection process greatly improves our efficiency.

An API provides automated access to a system's functionality for integration with other systems and the development of new user experiences, greatly increasing user efficiency for tasks spanning multiple systems. As your organisation grows, the need for new integrations and unified tasks across systems also grows. Organisations that avoid these necessities create disproportionate manual activities as a coping mechanism. This avoidance reduces client impact because funding is wasted on unnecessary human effort to work around these inefficiencies every week, fortnight, month, quarter, and so on.

There is no point in buying software that perfectly matches your needs if it has no APIs or poor APIs. Likewise, APIs that don't provide access to all system features are useless. This partial coverage is a fail because you can't predict which features will be needed for your integrations and custom experiences. Almost always, the features you need are the ones not provided by the vendor for some bizarre reason.

The APIs must be well-documented. Without proper documentation, the cost of creating custom integrations and experiences becomes so high that it renders the APIs effectively pointless. Defining a standard for documentation quality is straightforward—you can use an existing example. My go-to standard is the documentation provided by Stripe. I've never had a developer complain about it. They even use open standards that other software vendors can freely adopt.

Additionally, the APIs must be publicly testable. This ensures the efficiency of building custom integrations and experiences. If vendor interaction is required at any point, the effort to build these customisations becomes impractical. We're talking about a difference of a few hours versus several weeks. I can provide examples where we've tried both approaches on the same project.

In summary, rock-solid, high-quality APIs are essential for any organisation aiming to maximise its impact within its budget. Don’t bother assessing the business fit of any software until you’ve confirmed that it has APIs of sufficient quality.

There’s a chance you won’t find any software with strong APIs. This scenario is easier to manage than buying software with low-quality or no APIs. I will write about handling this situation soon.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.