What API is not about and about?

My team has been covering a potential customer for a while with regard to a API Gateway deployment. POC done. Presentation done. Then a competitor came in to disrupt ... it's common. Singapore is a saturated market. There are finite number of customers to chase after. If customers don't come to you and you hear that they are looking at a product from your competitor, you quickly go in to disrupt the market. 

If you are the product principal and you have the time and energy and you have a willing partner, then you will do this sort of things. I'm someone that is not too keen to do this. The pie is always big enough for everyone, that's my view. If you go in to disrupt the market, you're usually going into a price war. It's not about product superiority anymore. More importantly, the quality of the consultants are not considered.  

This is a vicious cycle. Nothing good will come out of it. Customers think they are getting a good deal. I say they are mostly blind. Partners/Vendors are not stupid either. If a partner bids with a superbly low price, you think the partner will give you his best consultants? You pay peanuts, you get monkeys. As simple as that. 

Anyway, I went in to make my last presentation. I only showed 2 slides. 

API is really not about Secure File Transfer, Security, Throttling and Message Queues. These are given. If a gateway has no such features, they will never get a chance into the board room in customers' place. 

Honestly, 80-90% of the API products out there in the market have similar features. All are equally good. Why? For most customers (80%), they only use a subset of features (20%). I can confidently say most API products meet the requirements of most customers. 

API is really about People - Customer & Vendor. 

I know that the competitor is partnering with a SI that does mostly systems related work - PAM, Secured File Transfer. 

In our experience, these type of people are only used 20% of the total time spent in a typical API projects. They are utilized during the Build phase and the Maintenance/Patching phase. In Build phase especially, my own experience told me that my API Consultants are of no use here. They simply do not understand networking, firewall, zoning, routing, high-availability, scaling, hardening, vulnerability assessment, security scanning. This is where a trained Systems Consultant is useful. They will be able to work with the Network Security team from the Customers' sides effectively. 

But as soon as the Build phase is over, the Systems Consultants become totally "useless". This is where API Consultants come in. They are there to help Customers with "Discover, Simplify, Transform, Add Values". In short, to provide API Design services. This usually takes up 80% of the total time spent in typical API projects.

API is all about proper thought process. It's not a simple "Oh, let's create a new API and map it 1-to-1 with your backend service". An intern will do! Why spend so much money?

.