Selecting the best vendor for your product


How would you like to shave 20% of your development time? How about 80%?

As Peter Drucker once put it:

    There is nothing quite so useless as doing with great efficiency something that should not be done at all

Vendors and the tools they produce help us avoid coding up features that could be more cheaply bought.

They come in all shapes and sizes including:

  1. Open source libraries (apt-get, bower install, composer install, pip install etc)
  2. API services (Apigility, NLP tools, Lorem generator etc)
  3. Cloud services (Firebase, Queueing , Realtime push etc)
  4. Frameworks (Django, Laravel, Angular etc)

And many more.

Considering how crucial all this vendors will be to your application and by extension your business. How do you choose which ones to use?

In this entry we look at some of the considerations to make when choosing a vendor.

How long has the vendor existed?

Experience is a harsh teacher but it teaches true. You want the builders of your tools to have undergone the test of time. Being a new product, your application is guaranteed to be teeming with bugs. You don’t want to ever be unsure if the bugs are in your code or the vendor’s code. Having a mature tool means that the vendor’s bugs have mostly been taken care of so now you can worry about your own bugs.

You should of course ensure that their experience has informed their iterations. Look at the release notes for signs of improvements over the various versions.

Are they committed?

For commercial products, it should be evident that the product they are peddling is an important one in their portfolio. Peripheral products suffer the risk of abandonment on short or no notice at all.

For open source projects, look out for a core team of long term contributors. You can bet this contributors have given their soul to the project and are not likely to give up on it now.

What would happen if vendor abandons it?

A lot of projects would wither and die if the project sponsor abandoned it. Some projects however have managed to attract a community around it and some even have an entire ecosystem.

The second kind of project is the one you want to use on your development. You can be sure even if the vendor abandons it, there will be a line of others waiting to support it.

Can you maintain the project?

If the tool is critical to your product, then you must consider your own ability to support it. In addition to the risk of abandonment, you also face the risk of the vendor evolving the product such that it no longer matches your priorities. If that does happen you must have carried out due diligence to ensure that:

  • The source code is available to you
  • The code quality is of an acceptable standard
  • You have personnel with the requisite skills

How do you decide which vendor to use for your own product? Talk to me on the comment section below or on my twitter @ jchex


Published by


Software Project Manager